The Infosys Labs research blog tracks trends in technology with a focus on applied research in Information and Communication Technology (ICT)

« October 2009 | Main | January 2010 »

November 29, 2009

Business Collaboration - Is it a Business Function or Business Capability?

I am new to "Technology Enabled Collaboration in an Enterprise" as a subject. I list here a perspective of traditional, competitive business and the structure of how people, process and tools/technologies so far has come closer to achieve the enterprise vision.

First things first - Questions
First few questions to probe from a CXO Community/Operational Manager perspective:
1.    Does the CXO community really care about the ROI for an Email communication application and if so how exactly to calculate and suggest the ROI for an email application?
2.    Does the CXO community is worried about a communicator application and its usage towards improving productivity or decreasing productivity for its employees? How to gauge the value of the communicator application? What is the relationship between communicator application and the business processes upon which the Role/Actor act upon?
3.    As Operational Managers, do we try to monitor the telephone usage of employees towards each of the projects/project codes running in our enterprise - towards analyzing the spend on telephone usage and its implied productivity improvement?
4.    There is a million dollar investment for a new product development in a technology company - what is the traditional way of collaborating compared to modern way of collaborating here? What is the impact of collaborative technologies/enablers towards Apple MacBook development - a pizza chart on the collaborative technology impact towards incubating, designing, developing, producing and delivering the product - over the entire lifecycle would be helpful for managers to organize their efforts for utilizing technology based collaborative enablers? A complex product like a Steam Engine produced by GE Energy needs multiple hundreds of parts assembled together and sourced from hundreds of vendors from hundreds of locations - all these things should go along well within six sigma limits for defects - what is the difference from traditional way of collaborating and technology enabled way of collaborating here? Does technology enabled collaboration affects the main goal - getting innovating ideas organized and developing the product itself in an efficient way or just enabling ways of documenting easier and structuring contents easier and may be reaching to the various teams quickly through video conferencing and net meeting? How to analyze and what are all the metrics to use to define the enabler technologies towards achieving the main goal of innovative product development?
Post those generic queries, I come to the classical definition of Business Functions and Business Capabilities.
Business Function:
My take on Business Function is something like this: 'An abstracted group of processes that are related and can be grouped together to make it work smoother or to define a vision for it and able to track it effectively'. DoDAF defines Business Function as "Action for which a person or thing is specially designed, fitted, used, or intended to accomplish or execute". Examples of business function include Sales, Marketing, Human Resource, Production, Supply Chain Management, Brand Management, Accounting, Reporting, Procurement etc. So, now as a CXO community member, I want an analysis - which are all my business functions that are performing well and how to identify to improve the performance of those business functions. I have a problem in Supply Chain Function and I need to understand the problem, the root cause and a solution approach - I get a business architect - he analyses the function through mapping the function, decomposing functions to business processes and then associates various enterprise resources to these business processes and completes the mapping excercise - we need to remember here by resources I mean inputs to business processes - organization, location, information/data, knowledge - structured and unstructured, events, application, technology and physical resources. Later he associates the goals and KPI for the function and the process. So, what the architect has captured essentially is the landscape of the function that can be modeled - the bones, flesh and organs of the function body. What about blood and the network that flows message from the neurons to the hand to make the movement - the "network or the networking context"? So, elaborating Business Function and organizing information around business function and processes are traditionally done this way - giving a structure and trying to incorporate measures to maintain the structure; there is less on the life of the structure - is this networking is enabling organs connect to each other to enable the body to deliver movements - run, sit and jump? Is this collaboration? So, traditional problem solving approaches for enterprise function analysis is to extended beyond modeling and process improvement?
Business Capabilities:
My take on business capability is something like this: 'An inclusive set of processes managed by role-players with a specific skill to perform them'. DoDAF defines business capability as: "The ability to execute a specified course of action 2. The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks". Think of a Lego Set - the blocks are your functions or processes, but the ability to organize the blocks to create a structure is 'capability'. That’s the reason why enterprises take a capability viewpoint - to define what is that they are good at and how to improve or utilize the something that we are good in doing at. Take a cricket team - the primary activities or functions are score runs, take wickets and save runs (field). But there are capabilities that allow to organize these primary activities effectively - Build Partnerships, Rotation of Players and Effective Running between wickets - these are capabilities to improve score runs activity. Similarly, Effective Seam bowling and Pace/spin combo can be capabilities to take wickets. From a business perspective, New Product Development can be a function, but effective innovating can be a capability that the enterprise has developed or nurtured over a period of time - though everyone make car, Honda is good at making fuel efficient engines - that’s their capability and it in turn might be elaborated as the ability to have a modular mind set and technology investment that has enabled Honda to be creative in designing fuel efficient engines. A hospital can be good in acquiring or attracting experienced doctors - that’s a capability; at the same time it might be bad in running a pharmacy alongside the hospital - outsource it. So, identifying capabilities and the subtle details around it is essential for competitive advantage. Again it boils down to the same question - how to identify, nurture and reap capabilities - is there a way to bring in my best people and technology together to provide the enterprise the ability to lead and excel in our market? This is a flat world - so capabilities which are flexible or modular enough is the need of the hour rather than rigid and holy stone imprinted processes. Can collaboration enable business capability improvement?
So the confusion I have is this: Is business collaboration is to be considered as function in itself (may be primary or secondary function while defining the Value Chain for the enterprise) and the enterprise is to define processes, policies and governance for collaboration; Or is business collaboration is an enterprise capability that is the need of the hour and it is indeed 'the' capability that cuts across other capabilities as well and so, to be treated to appreciate it in a modular, fast changing and always to be challenged capability?

Final word is: Enterprises are to have a "mechanism" in place to address business collaboration internal and external either as a business function or a business capability. Having this "mechanism" is the first thing; later comes the best of breed technology as an address to the mechanism.

November 23, 2009

Gartner EA Magic Quadrant 2009......what's in store.....

The recent Gartner Enterprise Architecture Magic Quadrant was released on Nov 12th. There is good sign for EA in the economic downturn scenario - it is reported that EA tool vendors have reported revenue growth of greater than 20% in 2008 as well as growth throughout 2009. From M&A among tool vendors, the most watched out M&A of Software AG acquisition of IDS Scheer is expected to get completed in 2009. EA tools are essential to the survival of EA as a concept as well as to cope up with the need to organize enterprise information in a structured manner - EA is a complex, mammoth documentation and business reporting effort.


IBM (erstwhile Telelogic System Architect), IDS Scheer Aris, Troux Technologies, Metastorm,Mega and alfabet are in the Leader's quadrant. It is important to note that Microsoft Visio doesn’t feature here. As per Gartner’s definition of minimum requirements of EA tool – there should be ability to create or import models & artifacts and ability to support repository information to support varied stakeholders and providing executable forms are essential as well a robust and flexible repository and meta models availability. Visio shall not fall under these essential minimum requirements – given that Visio plays a major role in BPM initiatives, how Enterprise Architects would consider these requirements would be good to know.


This year, no tool vendor falls in the Visionaries quadrant. It is important to note Casewise Corporate Modeler in the niche player quadrant. According to Gartner, a niche player has strengths in numerous aspects of EA but falls short in the market. Casewise supports a large number of EA frameworks and also has its own EA framework though it is closer to Zachmann framework. Casewise supports process execution through Corporate Synergy (a BPMS suite) as well simulation ability for process models. In this angle, Casewise is a good contender for a full scale EA tool vendor.


The magic quadrant goes on to list the strength and cautions for those tool vendors listed in the quadrant. It is also interesting to note that Magic Quadrant doesn’t include tool vendors like Sparx System (Enterprise Architect), avolution, bizzdesign and igrafx.


We don’t know the ‘magic’ with which Gartner comes out with Magic Quadrant, but it is a good start to organize tool vendor knowledge for EA community and business decision maker community for enterprises embarking on EA journey.

Promotional Copy of Gartner Magic Quadrant is available from Troux Technologies website :


Business Intelligence and Analytics - Challenges and Trends

In this post, I am planning to address the Business Issues and Customer challenges in today’s dynamic environment of Business Intelligence and Analytics. I will also cover the trends which are emerging and re-shaping the way corporate and organizations are doing their Business Analytics. As a consequence of recession during 2009, and the downturn, industry has seen the differentiators between organizations would be the strategies they are adopting especially on the line of alignment between IT and Businesses.

Gartner view on strategies for alignment between IT and Business primarily focuses on following aspects:

• How well the enterprises calculate their risk appetite – country of operations, verticals etc
• Business decision makers focusing on IT strategy and integrating it with their business strategy
• IT increasingly will be used by organizations to ‘grow’ and ‘transform’ the organization – compared to old view of IT as a tool for running the organization
• IT investment to be planned based on the values provided by investment in immediate past

Challenges faced by the Industry post recession

• Shrinking IT departments – manpower and infrastructure downsizing, despite the growing needs to build BI and Analytical platforms is becoming increasingly difficult to manage
• Reduced software spending and budgets – CIO’s are constantly being faced with challenges to manage cost on licensing hardware and software, added with outsourcing deals. Spending in BI/Analytics hence is getting tougher, and a much needed aid of free software
• Tolerance level on project acceptance – Business expectations on analytics are rising and expectations are to have minimal to no tolerance on errors, turn-around time cycles are reduced to add to challenges
• Business Dynamics – Organizations needs to understand constantly changing business environments, and the need two reduce IT costs while achieving new sales targets. This became even more evident during the recent recession and downturn witnessed by the industry across globe
• Faster ROI – Traditional BI and Analytics implementations typically required 12-24 months, and these are bigger bottlenecks for organizations to operate effectively and respond to fast changing market situations
• Scalability, Flexibility – Longer cycles of budget approvals for scaling hardware and infrastructure for movement from small scale to enterprise level solutions. Adaption to the changing business dynamics and needs is a huge challenges for enterprises, as changes to existing BI infrastructure requires weeks to months
• Unstructured Integration – 70-80% of Information in mid-large sized organizations is lying untapped in the form of unstructured sources of data like text based documents, emails, online blogs, PDF’s, Wiki’s, Images etc. No single solution in market today addresses tapping those unstructured sources of information, and integrating with the structured piece to get a holistic view Information and perform analysis

Top Trends shaping the BI/Analytics World

1. Cloud Computing – The definition, as with Web2.0, is varied basically Virtual servers available over internet to a broader definition of consuming anything outside the firewall of organization is “in the cloud”. The cloud computing attempts to address the always existing IT need:  a way to increase capabilities on the fly without investing in infrastructure, training resources, or licensing software. Core technologies supporting cloud computing are virtualization, automation, web-based computing, real-time, open standards.
2. Predictive Analytics – The value of predictive analytics is the discovery of unknown facts  and relationships, and leverage those relationships for effective decision making. Predictive analytics is the data mining solution focused on predicting future trends and probabilities, involving various disciplines such as statistical algorithms using probability & statistics, artificial intelligence, machine learning algorithms to solve business problems. The new step is to provide simulation, prediction, optimization and other analytics, not simply information, to empower even more decision flexibility at the time and place of every business process action. The new step looks into the future, predicting what can or will happen.
3. Open Source BI/Analytics – There no single technology conference, technology magazine, webinars/seminars or  BI/Data Warehousing online search which doesn’t talk about open source BI/Analytics. Few facts to share on progress of open source:
a. According to Aberdeen, 25% of their survey respondents will adopt open source BI in next 12 – 24 months
b. Open Source CEO’s agree that open source is a worldwide growth story
c. First 9 months of 2007 saw open source deals doubled each quarter
4. Recognizing the value of Un-structured Information – Marrying of structured and un-structured data assets will continue to evolve, and effective ways to un-cover the secrets hidden in the unstructured sources of information will shape in coming months and years. The information sources could range from customer emails, chats, blogs, telephonic conversations or help desk calls, RSS feeds, documents like text or PDF’s are all relevant and immensely informational rich content to be brought into analytics for effective decision making.
5. Green Computing – Today organizations are sensitive and more aware of reducing their carbon footprint via different methods like reducing paper consumption, reduced power usage, cooling costs, reducing travel etc. BI has been well positioned on reducing paper consumption by pushing majority of reporting needs, and information availability online thru various channels like internet, mobile, desktops. Linking BI with the mainframe systems for monitoring, performance analysis and reporting the power consumption can be targeted for transaction processing instead of just keeping the server lights on.
6. Data Visualization – is all about effective way of visualizing & communicating the information value of the data. BI has been on the forefront on the various data visualization offerings that let organizations create advanced data visualizations for their dashboards ranging from interactive charting to visualization capabilities found today across modern BI reporting, score carding, what-if analysis and dash boarding capabilities. The trend towards exploration of highly effective & interactive presentations through visualization will continue in the field of Analytics.
7. Mobile – Mobile is used to indicate applications that extend outside of the traditional office environment on devices other than traditional desktop or laptop computers. According to Gartner research, by year-end 2010, approximately 1.2-billion people will carry handsets capable of rich, mobile commerce providing a rich environment for the convergence of mobility and the web. The message-focused approach of mobile solutions lets short, smart messages be delivered through BI event notification technology to mobile clients. The fairly recent intersection of wireless devices and BI lets mobile business users and executives more easily view and interact with the same analytics they would find on their desktop via their mobile device for efficient decision-making. By drawing and combining information from GPS devices, demographics, maps and a customer’s database, location intelligence tools augment traditional BI analytics with important location-centric information. Beyond the mobility of people, the mobility of other assets tracked using RFID sensors, will become increasingly important. As these devices evolve and begin interacting with things like road or department store sensors, new business applications for analytics over mobile devices are possible
8. Composite Applications (a fallout of Web2.0) – The term Mashups loosely integrates and combines content from disparate applications, e.g. RSS feeds, exposed API’s, online resources, other unstructured web resources. Today’s BI reporting is moving towards a well knit integration of those mashups into the BI reports, dashboards and portals. This trend is to continue with the evolution of Web2.0 and growing awareness of integrated applications and content needs.

• “10 Red Hot BI Trends” – by Don Campbell.
• “Market Trends 2010: The Gartner View” – by Abhishek Raval.
• “Open Sesame: Why Open Source BI, Data Integration, and Data Warehousing Solutions are Gaining in Acceptance” – by Claudia Imhoff. Intelligence Solutions, Inc.

November 19, 2009

Business Architecture Series: Who is a business architect?

Sometime before, I wrote in another forum, regarding the hot topic of ‘Who is a business architect (BA)’ – what is the underlying ability a consultant should have in order to qualify as a business architect? These are the following options I listed down:


1)    Is BA is a person who has considerable amount of experience (around 8 to 10 years) in business decision making - have been part of strategy development and corporate planning and finally turned out to be architect advising/consulting EA initiatives of organizations?

2)    Is BA is Business Analyst turned Architect (more like technical analyst/system analyst turned IT Architect) over a standard amount of experience (5 + years) in business analysis, requirements engineering and process modeling?

3)    Is BA is a "management consultant" who has knowledge/capabilities on helping organizations/business units decide their strategic objectives; a person with considerable amount (5+ years) of experience in appreciating business motivation (goal/objective/strategy/tactics), business situation (market trends, economic conditions etc) and business project management?

4)    Is he an IT project manager turned BA over a considerable amount of experience (12+years) in handling multiple IT projects/application releases and who is having a bend towards understanding business? A person who can appreciate business needs and IT delivery?

5)    An EA who has performed mostly application architecture, information architecture and technology architecture for a considerable amount of time (10 + years) and currently consults for BA?

6)    Or simply a BA is an internal resource of the organization, who, has been groomed by the EA program or participated heavily on business decision making and corporate planning as well financial planning functions?

The answer is a mix and match of all these things and each one of them qualifies to become a Business Architect. This is more towards a role specification for being a business architect – I shall talk about the essential things (subject and concepts) business architect should be aware of soon………….

November 10, 2009

Business Architecture Series: Define Business Architecture in 140 words

Was reading through the book Re-imagine! by Tom Peters. In the foreword, he defines/explains short and sweet “what is an Enterprise”. I quote him here: “Enterprise at its best is…… emotional, vital, innovative, joyful, creative, entrepreneurial endeavor that elicits maximum concerted human potential in pursuit of Excellence and the wholehearted provision of services to others”. An amazing abstraction defining what is an Enterprise.

Would like to attempt an elevator pitch type’s definition for Enterprise Business Architecture (EBA). In one of my previous research publication, an attempt to define EBA was made:  EBA can be defined as, “the structure of business related components and the manner in which these components interrelate among themselves and other architectures viz., data, application, technology, to create business value”.

In my another research publication, an attempt to define Applied EBA was made: Applied EBA can be defined as, “an organization’s blueprint that helps in formalizing and analyzing business motivation and business behavior; it also helps in monitoring strategy execution for specific business scenarios in order to create better business value”.

I make another attempt here to be even more short and sweet or rather crispier: “Business Architecture is all about blueprinting business motivation, business behavior and business execution; it is 30% motivation architecture, 50% process architecture and 20% performance architecture”

I shall continue to define in depth business architecture in upcoming blogs………

November 7, 2009

Does your business strategy manifests in your processes?

There is always the million dollar question of how to link the enterprise business strategy to operational processes so that the strategy gets executed effectively. Enterprises adopt various mechanisms and programs to institutionalize strategy. Strategy is like an invisible enigma. It drives the enterprise but it often does not manifests itself visibly. Enterprises these days try to socialize their strategy through Strategy Statements. But that is often not enough or rather not better than making it visible through linking the strategy element to process execution. If such a mechanism can be built in and consensus is reached on this mechanism, there will be improved evidence for strategy execution for business decision makers to make agile course correction of strategy.

There are three major phases/areas of Strategy Management:

1) Strategy Formulation/Development - This phase either has a process of devising it or done by intuition of leader or lead by leadership team or embedded already in the management team which guides the organization.

2) Strategy Communication - Which also has a process of doing it at times or manifests itself into operating strategies as understood by subsequent teams performing execution of the strategy. This communication depending upon the nature of it can be explicitly communicated or not so.

3) Strategy Execution - How exactly the strategy is executed or how it is manifested into action. This manifestation of strategy is to be resulted in the enterprise business processes or behavior.

The fourth aspect that am going to talk about is Structuring Strategy Architecture - this is about formalizing the strategy - this aspect cuts across all the three pieces above and tries to document these three phases effectively so that they can be tied together and monitored effectively. If we cannot monitor our processes, we are loosing sight of the goal. Same is the case with strategy monitoring. As part of Structuring Strategy Architecture, the business architect, should not only deduce all the aspects of these three phases and knit them together, but also help in devising a performance management approach to keep the progress in check.

And here comes the trouble - this work cuts across all the three phases but there are hurdles at every phase and the business architect may or may not be part of these three real phases as well - so how can one structure strategy?

Phase I (Strategy Formulation/Development) - Business Architect  (who is external to the enterprise) is not involved in this process. Strategy does not manifest visibly - it is in the leaders mind. So, how to interpret the strategy and document the strategy statement?

Phase II (Strategy Communication) - Business Architect may or may not get the real communication. He/She has to keep all their senses alert to identify what is communicated in the enterprise and how. How close or relevant is the communication happening is closer to the strategy devised - the fidelity of the communication is to be checked.

Phase III (Strategy Execution) - Business Architect got to check how the strategy is executed and advice about the nuances of improving it. This is more operational and process oriented - process architecture is the nature of the phase.

Having listed the hurdles for structuring strategy, is there an approach to "model" strategy - more like a process model which helps in structuring processes so as to bring in process thinking across the enterprise. The Business Motivation Model (BMM) of OMG provides a meta model for business motivation and strategy is an element in the meta model. BMM lists Strategy as a means to achieve business goal (end) - the right approach to achieve the business goals given the environmental constraints and risks. Apart from BMM, Strategy Map concept by Kaplan & Norton is another approach to list strategy and link them together logically.

If the enterprise has identified its process portfolio, then all the major processes should be linked to each of their goals - so this way one can associate processes and goals. To these high level goals (can be from balanced scorecard perspective or from other goal modeling techniques), the architect can try to list down possible strategy statements.  So, these strategy statements can either be readily available or to be built with discussion with stakeholders. If this is listed against each goal for the major processes, then the enterprise decision makers can have a view of business processes to goals to strategy. Strategy does not have any properties - except shelf life for usage and applicability.  A goal has properties like sub goals, ownership, performance measures, quantifiable objective etc. Corporate Performance is measured as per the goals set and mostly not by the strategy adopted - but strategy is the means to achieve it - the cunning plan against competitive forces to reach the goal effectively.

Listing down strategies related to major processes of the enterprise is a challenge. If done so and linked along with goals which are in turn associated with the processes, it can definitely lead to effective decision making for sure............

November 5, 2009

Process Architecture Blueprint Definition - See the forest inorder to see the trees......

Organizations struggle to define their Process Architecture Blueprint which represents the portfolio of business processes of the organization. Process Architecture definition is a crucial phase in the development of BPM as well as Enterprise Business Architecture solution. Enterprises often take a piecemeal approach while defining process architecture blueprint and jump directly into modeling task level business processes without able to link to the end to end value stream of the business effectively. An attempt to have a structured approach to define the process architecture blueprint through defining what is process architecture blueprint, why it is needed, how to build it and how quickly one can build it is essential for an enterprise's BPM or Business Architecture journey. Success of Business Process Management teams depends on this crucial phase of process architecture definition and here I attempt to provide a framework helping enterprises embark into process journey.

What is Process Architecture Blueprint?

Process Architecture Blueprint is the schema of representing enterprise business process ontology. Process Architecture Blueprint is the high level arrangement of business process information of the enterprise in a way that represents maximum information about the enterprise processes in an easily interpretable as well as relevant manner. Process Architecture Blueprint can be visually represented as per the needs and culture of the enterprise to appreciate its process portfolio. The visual representation can be a value chain view, business capability view, value stream view or a business context view.

Process Architecture Blueprint also represents the business processes from different perspectives of various stakeholders of business and provides a map of the business processes. There can be three different kinds of perspectives of business processes:
1.    Enterprise Level Processes – Value Chain and Value Stream – Concern to the CxO Community
2.    Strategic/Functional Level Processes – High Level Functions and Major Processes – Concern to the Middle Management Community
3.    Operational Level Processes – Business Workflow and System Workflow – Concern to the Operational Management Community

There are other stakeholders and their perspectives as well that shapes the process architecture blueprint:
1.    Enterprise Architecture Team – Responsible for running and maintaining technology projects across the enterprise. Also responsible for aligning Business and IT.
2.    Compliance Management Team – Responsible for making sure business processes are compliant enough to regulatory standards and organization policies
3.    Six Sigma/Lean Teams – Responsible for process improvement, process governance and process harmonization across the enterprise

Why we need Process Architecture Blueprint?

Having a Process Architecture set up in place helps spread transparency of process knowledge amongst various team members and helps develop a process thinking culture within the enterprise. Also it leads to structured analysis of business processes for effective decision making.
1.    Enterprise Level Business Processes – Provides management overview for everyone in the enterprise; Describes overall function of the enterprise and includes value chain elements, value stream elements, business capabilities and business motivation elements; this level is at 10,000 feet above ground – highly broad.
2.    Strategic Level/Functional Level Processes – Describes major processes and sub processes and how they interrelate; Ideal to understand business function, goals of processes, strategy execution, ownership of processes and KPI; this level is at 1,000 feet above ground – fairly broad.
3.    Operational Level Business Processes – Describes task flows, decisions and process steps; from a system perspective, this level helps in defining use-cases; this level is too detailed for any strategic level decision making but includes many business rules that governs processes; this level is 100 feet high – just enough.
Having defined a process architecture blueprint brings in consensus over enterprise processes and helps socialize business processes across the enterprise.

How to build a Process Architecture Blueprint?

There can be three different approaches to build a process architecture blueprint:
1.    Clean Slate Approach – Here we have to start afresh, define process architecture standards, define what process architecture blueprint we want and work towards defining enterprise vocabulary and semantics.
2.    Quick and Dirty Approach – Here we develop something out of the existing information and validate it, refine the process architecture standards, align process architecture blueprint to existing information and refine enterprise vocabulary and semantics
3.    Structured Approach – Here we elicit process information through structured set up and simultaneously validate them with stakeholders, address correct need for process architecture standards, align process architecture blueprint to existing information and refine enterprise vocabulary and semantics

How quickly one can build a Process Architecture Blueprint?

It is to be noted that all these three approaches are time consuming because it is necessary to get consensus on what we build as well socialize the process portfolio list. For example, for the Quick and Dirty approach, I list a three step approach:
1.    Step 1 – What blueprint we want – reaching consensus. This step is all about reaching consensus on the view we want to build – value chain view, value stream view, business capability view, organizational model, functional overview etc. This might take about 3 to 4 weeks if we knock the right stakeholders.
2.    Step 2 – Define structured questionnaire for eliciting information for the blueprint and conduct workshops. This step is all about gathering existing information, assessing and deciphering information quickly, meet stakeholders, explain and gather information as required. This might take about 4 to 6 weeks if we knock the right stakeholders. By this step, for example we will be able to list the sequence of major processes that form part various value stream.
3.    Step 3 – Model the blueprint big picture, validate and socialize. Take a practical perspective, draw/represent the view, get it validated and freeze it till further review.

Process Architecture definition is a challenging but rewarding journey. One has to see the forest first in order to see the trees. So, having the portfolio of business processes represented through a blueprint definition is essential so that one can model the rest of the process hierarchy leading to various process analysis, improvement and spread of process knowledge transparency.

Subscribe to this blog's feed

Follow us on