The Knowledge Management (KM) Plan provides a detailed description of how knowledge, information, and data are shared across the enterprise. The KM Plan includes descriptions and diagrams of information sharing between systems, applications, knowledge warehouses, and databases. The KM Plan includes:
The approach to managing data, information, knowledge across the enterprise
How data and information-sharing support the Business Plan
Data and information-sharing strategies and diagrams for each line of business
Which types of data in the enterprise require extra protection
The lifecycle for data and information that is key to the success of the enterprise (data creation, sharing, updating, storage, retrieval, and deletion)
A high-level Concept of Operations graphic to depict the KM strategy
A KM plan involves a survey of corporate goals and a close examination of the tools, both traditional and technical, that are required for addressing the needs of the company. The challenge is to select or build software that fits the context of the overall plan and encourage employees to share information.
A KM plan should focus on enabling and improving LOB workflows and processes that involve information exchanges.
The KM plan should support EA standards for business process reengineering, improvement, and management.
A semantic data model can be developed using traditional structured methods and symbology (Entity Relationship Diagram), or one can use the object-oriented method and symbology of the Unified Modeling Language (UML), which produces a Class Diagram or Object Diagram (Entity Relationship Diagram).
An Investment Business Case uses a standard format to describe the value, risk, and return on investments made in technology and other resources. The Business Case also contains an alternatives analysis, program performance tracking metrics, architecture information, and security status information. It should include:
New Requirement Description
Existing Solution Check
New Solution Business Case
New Solution Evaluation
New Solution Approval
New Solution Implementation -> Benefit Realization
Example
1. New Requirement. A new requirement for resource(s) or support is identified in a line of business (LOB), which is brought to the EA and capital planning teams for evaluation.
2. Existing Solution Check. The EA and capital planning teams determine that an existing EA component cannot meet the requirement.
3. New Solution Business Case. The sponsoring LOB determines that the requirement is of sufficient importance to merit the cost of developing a business case:
Business Need. Describe the requirement in terms of the gap in operational or administrative performance it represents to the LOB and the enterprise.
Impact if Not Resolved. Describe the impact to the enterprise if the performance gap is not resolved, including strategic, business, and technology impact.
Alternatives Analysis. Identify 3 or more viable alternative solutions (if 3 exist).
Cost-Benefit Analysis. Quantify the direct and indirect costs and benefits for each alternative on a lifecycle basis, including qualitative items.
Return on Investment. Do a ROI calculation for each alternative.
Net Present Value Adjustment. Do a NPV adjustment for each ROI calculation to account for anticipated cost increases over the investment’s lifecycle.
4. Business Case Evaluation. The business case’s alternatives are evaluated by the Architecture Working Group (AWG) for the correctness of the analysis, and alignment with the EA at each level of the framework. The Capital Planning Working Group (CPWG) then reviews the business case for the correctness of the financial analysis. A coordinated recommendation is made to the executive-level Capital Planning Board (CPB) as to whether the business case should be approved or disapproved.
5. Business Case Approval. The CPB reviews and approves/disapproves the business case in the context of the enterprise’s overall investment portfolio using criteria that identify value from a strategic, business, and technology perspective:
6. Implementation. If the business case is “selected” (approved) for funding by the CPB, the proposed solution becomes an implementation project that is managed by the sponsoring LOB. The project is reviewed by the CPB at key milestones and/or periodically as part of the capital planning process’ oversight of all projects.
A Use Case narrative follows the Unified Modeling Language (UML) format for identifying business requirements, their context, stakeholders, and business rules for their interaction with systems, services, and applications that are identified as technology solutions requiring development.
The Organization Chart shows how positions and personnel are organized in hierarchical diagrams or matrix formats. Organization Charts help to show lines of authority, working relationships, as well as ownership of resources, products, and processes.
a service that is delivered to business customers by business units. For example, delivery of financial services to customers of a bank, or goods to the customers of a retail store. Successful delivery of business services often depends on one or more IT services. A business service may consist almost entirely of an IT service – for example, an online banking service or an external website where product orders can be placed by business customers.
The Node Connectivity Diagram shows the operational nodes, activities performed at each node, node-to-node relationships, and information exchanges. The purpose of this diagram is to show, at a high level, who are the operating groups in the enterprise (lines of business) and how they share information.
The Business Plan provides a high-level description of the key line of business functions, and financial strategy that will accomplish the strategic goals and initiatives.
Description
The following items are often found in a Business Plan:
1. Business Overview
2. Executive Team Profile
3. Relationship of Business Activities to Strategic Goals
The Business Activity & Product Matrix maps the lifecycle of revenue-producing products to various lines of business throughout the enterprise. This matrix highlights who owns business processes and products, as well as the extent of supply chains.
Example
The Activity/Product Matrix maps the lifecycle of each revenue-producing product that the enterprise produces to the line(s) of business that support one or more phases of the product lifecycle. This matrix allows the enterprise to see where the vertical and horizontal (cross-cutting) business product activities are located, as well as to help define ownership of those processes. The B-5 Activity/Product Matrix can then be used with various Data & Information level artifacts (e.g. D-7 Activity/Entity Matrix) to further map the product lifecycle to requirements for data across the enterprise.
The product lifecycle illustrated in this example has five sequential stages (research and development, manufacturing, warehouse storage, sales/distribution, and servicing) and two parallel administrative functions (financials and legal). Product lifecycles are different within most enterprises, and adjustments to the B-5 matrix should be made accordingly.
The Business Process area spans one of the most diverse modeling fields in practice. Many tool vendors use proprietary modeling methods and notations, and the international standards in the field are weak.
IDEF0 Business Process Diagram
BPMN Business Process Diagram
Swim Lane Process Diagram
IDEF0 Business Process Diagram
A Business Process Diagram shows a detailed breakdown of an activity, including how each step in the activity relates to the others.
The diagram follows the IDEF-0 modeling technique to show what the inputs, controls, outputs, and mechanisms are for each step in the process. This method for modeling business processes is known as the Integration Definition for Function (IDEF) technique. Developed in the mid-1970’s for modeling complex military projects,
IDEF-0 activity modeling is suitable for business process documentation in that it provides both high level context views, and more detailed views of each step in the activity in a format that can be further decomposed and interrelated with other processes to show linkages. This type of diagram is useful in showing linkages between steps and internal/external influences, but may not indicate a time sequence.
IDEF-0 uses Inputs, Outputs, Controls and Mechanisms (ICOM) to show the parts of an activity within an enterprise.:
Inputs: Items that initiate/trigger the activity and are transformed, consumed, or become part.
Controls: Guide or regulate the activity; usually indicate when/ how a process will be performed.
Outputs: The results produced by the activity; the reason for which the process was performed.
Mechanisms: Systems, people, and equipment used to perform the activity.
BPMN Business Process Diagram
Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model. It was previously known as Business Process Modeling Notation. Business Process Management Initiative (BPMI) developed BPMN, which has been maintained by the Object Management Group (OMG) since the two organizations merged in 2005. As of March 2011, the current version of BPMN is 2.0.
The Danish government earlier strongly promoted BPMN and made BPMN 1.1 an officially recommended standard in 2009. The Danish Local Government Association (KL) invested heavily in process diagraming work and sharing via Arbejdsgangsbanken, but decided to close / freeze it last Winter.
Recommendation: Use “BPMN Light”.
Swim Lane Process Diagram
A Stakeholder Activity Diagram shows which stakeholders (those with a vested interest in the enterprise) are involved with line of business processes, and the timing of that interaction. The diagram uses the format of ‘swim lanes’ to arrange stakeholders by row, and timeframes by column, then overlaying activities with flowchart symbology.