Posts Tagged ‘Business Model’

Business Process Modeling Methodology - Part 2

Sunday, May 24th, 2009

 

 

 

As we continue with the second part of the “Business Process Modeling Methodology” article lets take a moment to recap.

 

As you may recall from the first part of this article, our business process patterns methodology consist of the followings:

 

·         Value Chain – BPP1

·         Expansion – BPP2

·         Business Architecture\Renovation – BPP3

·         Resources – BPP4

 

The four BPP’s have internal processes that 1) execute, 2) manage, and 3) provide state and status.

 

We will now descend from the 25,000-foot level to final approach with the integrals of the BPP’s.

 The Value Chain BPP 

The Value Chain processes consist of activates, task, and events that process incoming logistics that in turn are guided through the enterprise to produce a valued product or service to the customer. The chain of activities that are the “Value Chain” provides the product(s)/service(s) greater value than the process before it. The Value Chain operatives are not to be confused with Supply Chain operations. Supply Chain processes feed into the Value Chain at different intervals of operations.   

 

The “primary activities” of the Value Chain include and are not limited to the following: incoming logistics, operations/productions, and outbound logistics such as raw materials that are sent away for construction and/or completion that in turn are provided back as value to the Value Chain processes. Marketing, sales activities, and service complete the primary activates. The “Resources” business process patterns also contribute to the Value Chain.

 

Here is an example of how we develop a new widget request from the market (customers) that feeds into the Value Chain:

 

The Business Process Pattern Flow

The Business Process Pattern Flow

 

Let examine the flow of this transaction: 

 Management decides to introduce a new widget for the market. The plan is formulated in the - Business Architecture\Renovation – BPP3  - pattern.

Business Architecture\Renovation – BPP3

Business ArchitectureRenovation – BPP3

 

Once the plan is completed it than proceeds to the – Expansion – BPP2 – at which time it is developed into the new widget.

 

Expansion – BPP2

Expansion – BPP2

  

After the development of the new widget, it is introduced to the - Value Chain – BPP1 – pattern for marketing and shipping. Also, status and state is sent back to Architecture\Renovation – BBP3  - pattern for monitoring and performance of the new widget.

 

 

Value Chain – BPP1

Value Chain – BPP1

Resources – BPP4, provides the resources such as materials, capital, human capital, etc. to bring the widget to life. We illustrate the importance of the transactions with external vendors in the case of creating the new widget. 

 

 

 

 

 

Resources – BPP4

Resources – BPP4

 

These individual breakdowns of the patterns may be applied to the following diagrams to come for a better understanding of their functionality in the given case. This also holds true for any process-modeling project given any enterprise type. One only needs to recall the four patterns definition and apply the functionality of it internals – Execute, Manage, Status, and State - to the project that will use the methodology.   

 

 

The Expansion BPP

 

Expansion, BPP2, manages and executes the enterprise growth. The processes involved are those that provide new development and capabilities such as new products, new services, new infrastructure, and enhanced or new processes.

 

During the formation or re-engineering of the enterprise, top-management has the responsibility to ensure that this BPP is created and formed to leverage scalability for the enterprise.

 

The internal processes of BPP2 may be composed of the following activates:

 

·         Evaluate new development and/or capabilities

·         Manage new development and/or capabilities

·         Design and create new capabilities

·         Provide feedback in terms of KPI’s (Key Performance Indicators), Scorecards, Dash boards, etc

 

Let us examine an expansion flow:

 

 

Expansion BPP2 - Flow

Expansion BPP2 - Flow

 

 

 

 

The Business Architecture\Renovation BPP

 

 

 

 

 

Every enterprise begins their journey by way of a thought that is transformed into a vision. That vision is than expanded into strategies that serves the marketplace with an entity of value. The “Business Architecture\Renovation” business pattern is the fundamental root of all processes. If this pattern is poorly implemented then the enterprise will render results that may fail the vision.

 

The internal processes of BPP3 generally have the following activates:

 

·         Define or enhance the enterprise vision and concepts

·         Transform the vision into strategy

·         Manage the strategy goals

·         Develop the goals

 

Here is a flow of the Business Architecture\Renovation BPP:

   

 

 

 

Architecture\Renovation BPP3 - Flow

ArchitectureRenovation BPP3 - Flow

 

The Resources BPP

 

 

 

 

An enterprise requires components (resources) to make it function. These components span a large spectrum of elements. These elements include everything from pencils to the human capital that use them, from CD-ROM’s to the Network infrastructure that communicates the data from them and much more.

 

The internal processes of BPP4 generally have the following activates:

 

·         Obtain resource type (Human, Capital, Infrastructure, Technology, etc.)

·         Decide and manage the application of the resources

·         Manage the strategy goals

·         Develop the goals

  

Here is a hiring scenario:

  

Resources BPP4 - Flow

Resources BPP4 - Flow

Now that we have landed at the completion of the serious, we trust that you comprehend the interworking of our “Business Process Modeling Methodology.”  This methodology may be plugged into any type of enterprise.

With a well-structured Enterprise Architecture Blueprint (EAB) and the embodiment of this modeling methodology within that blueprint, it enables any enterprise the assurance of success. 

 

This ends the discussion on our modelling methodology. For additional information please contact us

The Zachman Framework approach to EA

Friday, February 2nd, 2007

Stepping back from the current concerns with enterprise architectures, it is only fair to say that the IT people really began what has evolved into the current interest in architectures of all kinds. The earliest systematic use of the term “architecture” that is known of was in an article written by John Zachman, an IBM researcher, that appeared in the IBM Journal in 1987. The article was entitled, “A Framework for Information Systems Architecture,” and described how one could apply the concepts that building architects used to arrive at a number of perspectives that would help software engineers understand their own constructs.

A key idea was that an overall architecture was made up of a number of other architectures (LOBs) that were focused on different, specific areas of concern. Thus, the building architect created one diagram that he or she showed to the prospective buyers to give them an overview of what the finished product would look like.

Another blueprint was more detailed and described the rooms (using the analogy of building a house) within the structure, showing where the doors and windows would be, and so forth. Still more detailed views were created for the people who would actually build the infrastructure, while others were created for electricians, plumbers, and those who would finish the interior.

Zachman created a matrix that has six rows and three columns.

· The top row describes the Scope or overall context and is concerned with things a planner might consider.

· The second row describes a Business Model and is focused on things that might concern a business manager.

· The third row is focused on the System Model and is concerned with the logical elements that might interest a software designer.

The original Zachman framework was focused on Data, Functions, and Networks, and was properly identified as an “Information Systems Architecture.” In the past decade, Zachman has continued to expand his matrix. He has added three columns, People, Time, and Motivation, and has started calling it an Enterprise Architecture.

IT folks have a long tradition of using the term enterprise to refer to company-wide systems. Thus, Enterprise Applications originally referred to systems like accounting, payroll, and bookkeeping that were run on mainframes, maintained in central locations, and used to maintain a company’s accounts and generate all the paychecks.

Similarly, large companies have used layered diagrams to represent how their products can be arranged into a comprehensive IT solution, and, in the past few years, they have frequently referred to these comprehensive collections of products as an architecture.

If you view the Zachman framework, you’ll see that some of the cells within the matrix are described as architectures.

There are Application Architectures, Data Architectures, Human Interface Architectures and Network Architectures, among others. By the time Zachman completed the first version of this framework, he was convinced that he had identified all of the kinds of data that a company needed to keep track of, and, thus, the framework describes a kind of architecture of architectures. At the same time, the term “enterprise architecture” had become popular as a way of talking about all of architectures a company might need, and thus, the latest version of Zachman’s Framework has been termed an Enterprise Architecture.

Some would argue that Zachman’s Framework provides a comprehensive description equivalent to our use of the term Process-Centric Enterprise Architecture. A quick examination of the Zachman Framework, however, will suggest that business processes are not central to Zachman’s conception.

There is a lot of interest currently in the Zachman Framework. Some companies claim to use the Framework to organize their corporate data, and it is often cited as an example of an enterprise architecture. We well review other Enterprise Architectures in later writing.

Visit dotNet Framework Solutions for more information.