Supply Chains and Tiers
Copyright 2006 Robert J. Glushko
Business Patterns Assignment
Recognizing Documents
Roles in Document Analysis
Strategic and Tactical Document Analysis
Supply chains and tiers
Direct vs indirect procurement
Direct vs indirect distribution
Build to Order
Vendor Managed Inventory
Component assembly vs channel assembly
If a degree is defined as a set of courses, then the manufacturer is the department that brings the courses together to form the degree and the tier 1 suppliers are whoever puts together a course
Many of you had trouble distinguishing direct inputs from indirect ones
Many of you had some trouble with the role of the TA
Many of you had a simplified or incomplete understanding of the BTO pattern. The customer doesn't establish the possible configurations; Dell does
Likewise, BTO Berkeley won't sell degrees that "don't work" or that aren't competitive with those from other universities, but it will exercise "demand management" to shape demand
Plato was trying to get at issues of component standards, modular design to support reuse - critical issues in a BTO strategy
VMI and BTO are different patterns that generally apply to different industries
Some of you analyzed a combined pattern of BTO + VMI - that would be great for students because they'd always get into courses they wanted but terrible for instructors because they'd have uncapped responsibilities.
In previous courses I have asked students "who is the manufacturer or assembler of the degree product" instead of starting with the department as the manufacturer
There were many more variations (university, department, and professor each considered as manufacturer)
False positive analogy to "channel assembly" pattern even had some students treating the buyer/student as the assembler (confusing the "assembly" done by the manufacturer in the supply chain with the consolidation of knowledge across courses done by the buyer that happens in the "real world" but which I defined out of the model with the notion of "Bill of Materials" ) (wrong analogy)
EVALUATE AN INSTANTIATED PATTERN – "can the university be viewed as a marketplace operator that sells degrees manufactured by a school or department?"
INSTANTIATE A PATTERN – "how is the university like a supply chain and marketplace?"
SELECT A PATTERN – "here are some observations about the university - classes and majors are oversubscribed, some classes are underenrolled... how could you eliminate or reduce these problems?"
Models are simplified descriptions of a subject that abstract from its complexity to emphasize some features or characteristics while intentionally de-emphasizing others
There is an essential difference or gap between the real world being modeled and the conceptual world of the model, or else the model would serve no purpose
There are often tradeoffs between using patterns and creating a model "from scratch"
But usually these are lower costs than starting from nothing and it usually better to conform to or adapt a pattern than to build a custom solution
A pattern suggests roles, processes, and document exchanges so that choice of pattern makes a difference
Choosing a pattern is an iterative process
Whenever there is "business" going on almost by definition that means there are buyers and sellers, or producers and consumers. So we can apply that pattern to almost every situation to gain insights.
Who has the power, the buyer or seller?
Who can set standards or terms/conditions in the relationships? (who can choose the pattern?)
Who is the authoritative source of the information involved?
What kinds of products or goods are being "sold"
Every major advance in transportation, communications, manufacturing, financial technology or "governance" has required new types of documents
But the basic idea of a document has been surprisingly stable for a couple of millennia
A document is a self-contained package of related information
Documents organize business interactions around the information needed to carry out transactions
Documents are the inputs and outputs of business processes
In most Document Engineering efforts a critical step is creating a document inventory and classifying the "documents" you locate
You need to take a very broad view about what's a document because much of what's important to analyze isn't a traditional document
Much of what we analyze comes from people or systems or machines, and the line between "requirements analysis" and "document analysis" isn't sharp
Documents are packages used for exchanging information.
Packages may be:
Paper form (printed/written, formal/informal)
Digital form (computer files, structured/unstructured, databases)
Exchanges may be:
Messages (emails, EDI)
Online or Web
Postal, Fax
Sets of data in databases, spreadsheets, accounting systems
Printed or Web forms (and their source forms)
Documents that describe APIs or maybe even the code that implements them
Job aids, "cheat sheets," sticky notes and other informal or unofficial documents
Lots of undocumented information in people's heads that you write down after talking to them
Identifying all the potentially relevant documents or information sources is inherently an iterative task
If there are many instances of a particular type, we have to be concerned about representiveness and selection biases
Don't assume that job titles and formal organizational structure reflect what people actually do
Don't assume that the names given to documents fit the people, tasks, and organizations in which we locate them
Regardless of its title, make sure a document is being used before you conclude it is important
There are a few hundred common types of documents used in business transactions
But transactions are just one category of document types
Other categories with many distinct types include:
Software and system documentation
Procedures, policies, laws, and regulations
Reference books, encyclopedias, dictionaries
Catalogs
Organizations often use or produce multiple document types within the same category
Standard approach is facilitation by document analysis experts in face-to-face "workshops" with broad participation
Document creators/users reach consensus with expert help, and then experts systematize it into models and schemas
Document analysis is often carried out as a consulting engagement – with all the complications of defining the project, managing expectations and relationships, and packaging the results for effective use
What will they know?
What won't they know?
What factors will constrain their interactions with you?
This is YOUR role
What will you know?
What won't you know?
What factors will constrain your interactions with others?
Some sets of document types in an inventory are related to each other
Some document types are themselves sets of documents of another type
Other document types fit together in a kind of sequential or process relationship where information flows from one to another in the normal way in which they are used or created
Transactional documents often come in pairs that must be correlated
Documents can have complementary (they are useful together) or uncomplementary (they are not useful together) relationships, and the relationships aren't necessarily symmetric (depends on the perspective of the primary document for the user's activity or process)
Sometimes there are rules for names of document types
Sometimes there are rules for names of document instances
Sometimes the names of document types or instances aren't informative
Names are just one kind of metadata attached to document instances; there is lots more
For every document or information source you should collect:
Name
Source (where/who found)
Definition
?
?
Any metadata that helps you decide whether to analyze it
Sample from all parts of the document type spectrum
Sample more from heterogeneous categories
Sample documents based on priority of requirements
Sample based on importance or authoritativeness
Org charts can suggest business processes (and their associated documents), people who can tell us about them, and the context boundaries we can enforce
The level at which you interact with an organization - the kinds of people you interact with - strongly shapes what you learn about it
The concreteness of document analysis makes it more "bottom up" than business process analysis
Document Analysis IN a Strategic Effort:
HP merges with Compaq and assesses how each side does business to decide what practices/ orgs/people should be retained
One of the last phases of efforts like these is Document Analysis to ensure that the "keeper" processes of the merging firms are effectively combined
Document Analysis AS a Strategic Effort:
Analyze the information creation, management, processing, and distribution activities of an enterprise or organization to support the development of a data and process dictionary, an information architecture, or an enterprise data model
Often the foundation activity for introducing a "content management" or "knowledge management" system
Identify "overlaps, gaps, and opportunities" in alignment of information assets with goals of the enterprise
Eliminate redundancy, identify what information must be collected that isn't, and that which might be
Increase reuse
Increase consistency
Enable flexible creation of customized/personalized information products
There will be lots of documents and data sets to analyze, but this kind of effort will be much less focused on these existing information artifacts than a tactical document analysis project is
Analyze the existing information used by some constrained set of processes in an enterprise so that the processes can be improved, automated, re-engineered, re-purposed
Two most common tactical efforts:
Document automation
Online publishing
Transforming printed transactional documents or forms into electronic versions
The business driver is often a "request" by a dominant business to its partner to automate the exchange of transactional information in conformance with its proprietary document specifications
This means that the real goal can be to take an existing process (often, someone else's) and encode it in electronic documents
Creating an electronic version of a printed document
CD-based documents (late 1980s-mid 1990s)
Web has been the dominant medium since then
Limited amount of "e-books" on various devices
A "single-source" publishing strategy can be more strategic if it takes a comprehensive and end-to-end perspective on redesigning print-only publishing processes to take advantage of new formats and flexibility
Chapter 16 of Document Engineering Chapter 16, 540-554 ("Capability Assessment")
Document Engineering Chapter 9 ("Analyzing Business Processes")