BPM and the Knowledge Economy by Ronald G. Ross

BPM often simply overreaches.  Understanding, modeling, and managing a business effectively requires a balanced view of six basic questions, not just one, as given in Table 1.  I follow Zachman in these matters so, yes, the table is Zachmanesque.

	Interrogative	Basic Business Question	Kind of Model
1	What	What inventory of things needs to be managed to support business activity?	structural model (e.g., concept model,[1] data model)
2	How	How do transforms of things in business activity need to take place to add value?	process model
3	Where	Where does business activity occur?	network model
4	Who	Whocollaborates with whom to undertake business activity?	interaction model (e.g., organizational chart, use case)
5	When	When does business activity take place?	temporal model (e.g., schedule, event model, milestone model)
6	Why	Why are results of business activity deemed appropriate or not?	strategy model (e.g., Policy Charter,[2]constraint model)

If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others.  Your overall approach and architecture will reflect that.  You will naturally gravitate toward BPM.

That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:

• Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks.  C-suite executives tend to be much more focused on the latter.


• Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them.  As a result your process models will be unnecessarily complex and your overall solutions un-agile.


• Your approach will fall woefully short in addressing the intellectual capital that underlies your processes.  Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.

Fewer and fewer business problems these days fall into the nothing-but-widgets category.  Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.


2. Demonstrating compliance-based actual rules, rather than the artifacts and effects that IT systems produce.


3. Retaining, teaching, and repurposing intellectual capital.

These are not strengths of common BPM practices.

For all the non-widget-centric business activity in the world — which includes just about every conceivable form of white-collar work — these needs become paramount.  And make no mistake, the future lies with automation of that white-collar work.

What would I do to correct the shortcomings of BPM?  Our answer is to become more why-centric, as opposed to narrowly how-centric.  That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM).  Business goals and business risks should be drivers of business process design — not the other way around.  You need to be strategy-driven, not simply process-driven.


• Designing core metrics around business goals and business risks — the things that concern C-suite executives the most.


• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.


• Treating business rules as a first-class citizen, externalized from process models.^[3]


• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.


• Including a Why Button as part of every business solution.^[4]  Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

For further information, please visit BRSolutions.com      

References

[1]  Refer to Refer to Business Rule Concepts:   Getting to the Point of Knowledge (4th ed), by Ronald G. Ross, 2013, Chapter 1 and Part 2.   http://www.brsolutions.com/b_concepts.php  

[2]  Refer to Building Business Solutions:   Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd ed. (Sept, 2015), an IIBA Sponsored Handbook, Chapter 4.  http://www.brsolutions.com/b_building_business_solutions.php  

[3]  Refer to the Business Rules Manifesto, now in almost 20 languages:http://www.businessrulesgroup.org/brmanifesto.htm  

[4]  Refer to Ronald G. Ross, "The Why Engineer™," Business Rules Journal, Vol. 14, No. 11 (Nov. 2013), URL:  http://www.BRCommunity.com/a2013/b727.html 

SOURCE: Ronald G. Ross, "BPM and the Knowledge Economy," Business Rules Journal, Vol. 16, No. 11 (Nov. 2015), URL:  http://www.BRCommunity.com/a2015/b835.html  

Practical Process: The Primacy of Process

I believe that the primary focus of every organization should be the understanding, management, and continual improvement of the business processes by which customer value is created, accumulated, and delivered. Not the only focus, of course, but by far the most important. This is the essential message of process-based management and once that message is heard, the need for both process management and process improvement is obvious, urgent, and compelling. Let me explain what I mean by, and why I believe in, the ‘primacy of process`. This Column is deliberately short (if I had been in a hurry I would have written a longer one!) because I would like to find a way to succinctly define the key message of process-based management. Have I achieved that? Please let me know.

Process?

Why “process”? The simple view of a process is that it is a collection of cross-functional activities that transforms one or more inputs into one or more outputs. I also include all of the resources, people, systems, infrastructure, policies, regulations—everything that is required to execute and manage the process. Processes are important because this is how organizations get work done.

Primacy?

Why “prime”? Cross-functional business processes are the only way organizations can deliver value to customers and other stakeholders. By themselves, the separate functional areas of an organization cannot deliver value to external parties. An organization`s resources are managed ‘vertically` via the organization chart. Value is created, accumulated, and delivered ‘horizontally` across the organization chart.

It follows that an organization executes its strategic intent via its business processes. The sequence from strategy to execution is shown in the breakout box, From Strategy to Execution.

The only way an organization is able to exchange value with its customers and the way in which it executes its strategy—sounds prime to me!

Implications

If we accept that business processes are the value pathways, as well as the way organizational strategy is operationalized, where does that lead us? The inescapable conclusion must be that the starting point for effective organizational management is to understand, manage, and optimize those business processes. Without a proactive focus on business processes, organizational performance cannot be optimized and strategy cannot be effectively executed.

If value is created, accumulated, and delivered across the organization, what measurements of performance are made in that direction? Do we know if those cross-functional processes are working well? Do we know what “working well” would mean? Do we know where the performance gaps are and if anyone doing anything about them?

If value is created, accumulated, and delivered across the organization, who is in charge of that? The organization chart is silent on such cross-functional matters. Sure, we can say that the CEO is responsible for everything, but she knew that and it doesn`t help. Can it really be a good idea that the path through which we exchange value with our customers is not managed?

Relationship to Business/Enterprise Architecture

I`ve said that process performance should be the primary focus of an organization, but not the only focus. There are many other aspects and the positioning of the many other architectural elements naturally arises.

There are many “architecture” types. As well as business architectures and enterprise architectures, there are architectures that address IT, information, capabilities, services, systems, rules, applications, organizations, and people. This Column does not seek to either explain or reconcile the many views of business or enterprise architecture, but it does have a particular architectural stance—the primacy of process—and this requires that processes be the focal point of any architectural view. All of the common architectural perspectives are valid[1], but the process context is fundamental and each other perspective has a direct relationship to it. While other constructs are useful and often vital, particularly to guide information systems, the tendency to define ‘every` object and show the relationships to ‘every other` object via abstract diagrams, may be of limited benefit to managers.

Accepting the ‘primacy of process` principle, and starting with the process architecture, allows an organization to focus on the purpose and performance of the value pathways. Other architectural elements can be added when they are be shown to add value, when they are an aid to management and not a further complication.

Conclusions

Management needs its own disruption. A practical and pragmatic approach to understanding the organization as a system for value creation, accumulation, and delivery is required. Clear links between strategy and process execution must be defined. Mechanisms for identifying, managing, and improving process performance must be realized.

Organizations must reimagine their operations as value creation and delivery flows.

In Practice…

There are many things you might do in response to the issues discussed in this Column. Here are three practical steps you might consider doing now to get started on the creation of sustainable process-based management and process improvement.

Discover the value pathways

Document the process architecture for your organization. Find the strategy statements and determine who are the customers and other stakeholders and your organization`s value proposition for them. These are likely your core highest level processes. Decompose those processes down a level or two.

Agree on performance targets

If those processes were working as well as the key stakeholders would like them to, what would they be doing? How would you know? Define and document the critical few performance measures.

Mind the gaps

Capture the performance data and make evidence-based decisions about what to do for any performance gaps.

[1] Although I still struggle to see how ‘capabilities` add value that is not already provided by ‘processes`, but we`ll leave that for another day

SOURCE: BP Trends

What is the value of Business Architecture?

How Companies Break Into Emerging Markets

ITSM (IT Service Management) definition

Process management

The most widely used framework for IT process management is ITIL v3. ITIL was created because there was a need for ITSM best practice in the late 1980’s and it has since become the de facto framework used by many organizations across the world. The current version of ITIL incorporates an IT service lifecycle that has five parts: Strategy, Design, Transition, Operations and Continual Service Improvement.

1. Service Strategy

This is the start of the IT service lifecycle and is typically the area that needs most attention in IT organizations. Most organizations today focus on the Transition or Operations processes, and while these do provide benefits to the business, especially with regards to keeping the lights on, these are fairly well understood processes. Instead, there needs to be a shift to thinking more strategically about delivering value to the business, and this value creation starts with service strategy.

If IT can start thinking strategically in terms of how they add value to business outcomes, their mindset and culture will transform from a technology focus to a business focus.

Service Strategy helps to align business and IT strategies. It establishes priorities, confirms resource allocation, identifies constraints and risks, develops IT service portfolios and focuses on the reasons why the organization should do something, rather than the how.

Processes covered in this part of the lifecycle include: Strategy Management for IT services; Service Portfolio Management; Financial Management for IT services; Demand Management and Business Relationship Management.

2. Service Design

This stage in the IT service lifecycle takes the service strategy and turns it into a plan for delivering the business objectives. The old woodworking principle about ‘measure twice, cut once’, applies here. All too often IT spends insufficient time on Design and ends up building and implementing something that does not meet business needs. If the business, IT Enterprise Architecture, Development and Operations teams spent more time working together at this stage, the organization would save money: It is much more cost effective to resolve an issue identified in Design than waiting until Transition or Operations.

Service Design includes the whole IT organization, including internal/external service providers, process, people and technology. Thinking about all these areas ensures that the organization has an end-to-end plan for supporting the new or changed service once it is built in Transition and moved into live Operations.

Processes covered in this part of the lifecycle include: Design Coordination; Service Catalog Management; Service Level Management; Availability Management; Capacity Management; IT Service Continuity Management; Information Security Management and Supplier Management.

3. Service Transition

This takes key outputs from Service Design such as the Service Design Package (SDP) and prepares the new or changed services to go live in Service Operations. It helps to control and manage risk through the build and test phases.

Service Transition is about creating transition plans, testing services against the acceptance criteria developed in Design, controlling risk and preventing undesired consequences, and capturing and managing knowledge. It ensures that new or changed services meet the needs of the business as documented in the earlier lifecycle phases of Strategy and Design.

Processes covered in this part of the lifecycle include: Transition Planning and Support, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing; Change Evaluation and Knowledge Management.

4. Service Operations

This is where the rubber hits the road. It is where the value identified in Service Strategy, finally gets realized by the business. This lifecycle is the one that has received most attention, with Incident Management probably being the most popular process for improvement activities, which makes sense as it is the most visible process to the business and end users.

Service Operation is all about maintaining a stable IT environment through reactive and proactive means. This ‘Keeping The Lights On’ typically takes a lot of IT’s budget. Service Operation coordinates and executes the processes required to deliver and manage the end to end services agreed with the business.

This lifecycle is the one that mentions functions as well as processes; the Service Desk being the most well-known function. The other functions are Technical Management (The IT infrastructure resolver groups), IT Operations Management (Data Center and facilities) and Application Management.

Processes covered in this part of the lifecycle include: Event Management, Incident Management, Request Fulfillment, Access (Identity) Management and Problem Management.

5. Continual Service Improvement (CSI)

Taking the services from Strategy through Design, Transition and Operations is not the end point. All of the lifecycles are subject to improvement and the CSI lifecycle provides guidance and best practice for incremental and large scale improvements. There are many inputs to CSI, some examples include service level breach reports, process compliance exceptions, incident and problem trending, customer complaints etc. It is advised that using a closed loop system such as Deming’s Plan-Do-Check-Act, provides some structure for identifying and managing potential improvements.Using additional tools from lean and Six Sigma, work really well with CSI.

Processes covered in this part of the lifecycle include: 7 step improvement process; Service Reporting; Service Measurement.

Managing People

In order to make the best use of ITSM, the real change has to be effected by people. Processes and technology are key components of ITSM but only people change will sustain the improvements necessary. People change starts with education, and the ITIL v3 Foundation certification provides everyone with the right language and basic understanding to get things going. Every successful ITSM transformation begins with training the staff.

If you can get the ITIL process owners and process Design teams trained before you begin the process Design, you should be in a good place. Then you can train as many of the remaining IT teams as possible. Once Foundation training is complete, training the process owners to an ITIL Intermediate level will increase their level of understanding to that required for a Subject Matter Expert.

Communications is another key driver to facilitate behavioral change. People need to understand the ‘What’s In It For Me’ aspect and this can be achieved with a well-structured change framework:

• Making it essential –ensuring a sense of urgency and commitment is felt across the organization, and that individuals feel that change is essential for them personally as well as for the organization.
• Making it ready – identifying and influencing the levers for change across the organization, with appropriate underpinning planning - individuals feel prepared and equipped to absorb the change.
• Making it happen – driving and releasing implementation of the change initiative against the change plan, flexing as things change, during the change.
• Making it stick – ensuring measures are in place to continuously sustain and improve the benefits, and fine tuning the new ways of working to ensure they are reinforced sufficiently to become the norm.

The roles of service owner and process owner are critical in ITSM transformations:

Service owner

This person is accountable for the delivery of a service and acts as the key customer contact for all service related queries and issues. They need a detailed understanding of the end to end service and all the components that make up the service. They should develop the Total Cost of Ownership (TOC) model for the service. They interact with appropriate process owners; serve as the escalation point; understand and develop the capabilities to deliver the service, make improvements to the service and ensure the ongoing service delivery meets the agreed requirements of their customers.

Process owner

This person is accountable for making sure the process is fit for purpose and that it follows the documented process flows and narratives. They sponsor initial process Design; manage and sign off any changes to the process and process Key Performance Indicators (KPIs); address issues with process adherence; identify and manage improvement initiatives; conduct process maturity assessments, provide technology requirements to automate the process if feasible, and ensure process practitioners have all the required knowledge to conduct the process.

Technology

Most ITSM initiatives need service management tools to be successful but immediately purchasing a tool and thinking it will solve all the issues, is wrong but unfortunately a common mistake. The tool must support the process, not the other way round. A better approach would be to use the following phased approach: develop a process governance framework; Design your process; develop technology and data requirements and finally implement a technology solution.

Process Governance

The following activities should be undertaken: Establish process accountability; select and launch process improvement team; draft the project charter and plan; draft the communication plan; educate stakeholders with an executive overview and provide foundations training.

Process Design

The following activities should be undertaken: Document / review Supplier-Input-Process-Output-Customer (SIPOC); perform Voice of Customer (VOC); conduct Failure Modes Effects Analysis workshop to identify and prioritize waste; conduct Value Stream Mapping workshop to identify value; document current state (as-is Process) and identify process gaps; develop new process flow; develop metrics and baseline data; understand existing artifacts tools.

Technology/data Design

The following activities should be undertaken: Gather business requirements; develop conceptual solution architecture; develop logical solution architecture (if applicable); develop data model; develop physical solution architecture

Implementation

The following activities should be undertaken: Update to-be process as appropriate; implement solution; develop sales and operations plans (SOPs), training plan process controls; update process repository; develop  continuous process improvement plan; capture lessons learned.

Common management challenges

Service Strategy

Not putting enough time and effort into this lifecycle stage is the key issue.  IT has to move away from being looked at as a cost center and it will only do this when it stops becoming silo’d and becomes an end-to-end service-based organization that focuses on business outcomes and business values.

If we consider the output from an ATM service as being cash, does IT design and deliver end-to-end services to support this outcome, or does it focus on the silo’d technology for the service?

Service Design

Integration with the software development life cycle (SDLC). The Service Design Package can be integrated with the SDLC framework, so that all programs and projects follow the same common approach. The Design should include organizational readiness assessments so that thinking about knowledge transfer, KPIs and reports, the service model etc., is not left until the last minute.

All too often, thinking about the resources required to manage the new or changed services and what measures and metrics will be used to manage the services, is also left until the last minute. Designing and planning for this early in the service lifecycle is much more efficient and much more likely to result in the business receiving the outcomes they expect.

It is also difficult to develop the ability to define services and their SLA targets in business terms. As an example, how many IT organizations provide reports on revenue or compliance impacting incidents rather than the standard P1-P4 incident reporting? More work needs to be put into understanding the business and their language.

Service Transition

There are many challenges within Service Transition but with the way businesses are changing in today’s fast paced world, managing the dichotomy of maintaining a stable production environment and reacting quickly to business needs is one of the most difficult challenges.  The emergence of DevOps versus legacy waterfall type IT approaches is only going to exacerbate this challenge.

Service Operation

This lifecycle helps IT to fix the basics and earn the right to deliver further IT services.  It is essential for improving the actual and perceived performance of IT.  If IT can improve incident management across all priorities, not just the P1’s and P2’s, and if IT can improve request fulfillment, especially onboarding, it has a genuine chance of satisfying the business and their end users.  And this is where the main challenge is: Improving the service request and low priority incident performance.  Most IT organizations focus on the big outages: P1 and P2 incidents and do not focus on the higher volume, low impact incidents and requests.

With the service desk (SD) function in Service Operations, effectively being the window into IT, anything that impacts the SD is an issue.  If the relationship between the development teams and the operations teams is not good, this can be a big issue, especially if the development team throws new services over the wall’ to IT and leaves it to operations to run with.  These teams need to communicate very well and make sure that each is fully involved with onboarding new or changed services.

Continual Service Improvement (CSI)

 Management commitment is a challenge also applicable to all the other lifecycles but particularly for CSI.  IT normally has its hands full putting out fires and keeping the lights on and it doesn’t have much time for proactive CSI activities.  Leadership can energize this area by allocating a CSI manager and giving them the resources to instigate improvement initiatives.

Once this hurdle has been overcome, attention can then go to ensuring CSI has the right data to do its job and this means having reports with meaningful content.  Garbage in really does mean garbage out (GIGO) for CSI.  If you are attempting to analyze trends in incident resolution and the incident records are incorrectly classified, you will be trying to trend with bad data.  Bad data is one symptom of immature processes and maturing the processes to at least a basic level will help CSI improve them further.

SOURCE: SEARCHCIO

Creating Sustainable Process Based Management

For many organizations, and their teams and people, there is a significant disconnect between strategy and process, between the mission-vision-values statements or their equivalents and the business process pathways that operationalize the strategy. Strategy development is inherently a top-down activity. Business process management and improvement is often conducted in a bottom-up or middle-out fashion. With the strategic view ‘coming down’ and the process view ‘going up’ there is a real chance that both fade to gray before they meet. In the resulting ‘gray zone’ the strategy loses its clarity and purpose and process activity fails to coalesce into holistic management practice. Too many organizations end up with two seemingly unrelated conceptual views of the enterprise: the strategy, perhaps with strategy themes and a strategy map, and the process view shaped as value chains, process hierarchies and detailed models. Nice PowerPoint, love the artwork — but no practical support for improvement aspirations.

Developing a more coherent view of the inter-relationships between strategy and process makes it much more likely that the strategy will be executed and the processes will be effectively managed. Win-win. Let’s see how that might work.

Developing Strategy

I don’t want to downplay the difficulty and complexity of developing statements of strategic intent (mission, vision, value etc.) but it does seem that this activity is sometimes made more complex than it needs to be. Where there is disagreement amongst the stakeholders then, of course, that can make life very difficult. What need not be difficult is the approach to facilitating and resolving those discussions.

Developing strategy is essentially about answering three questions:

1. Who are we?
2. Who are our customers and other stakeholders?
3. What we do for each other?

Who are we? What do we want to achieve? What do we have to offer? What are our strengths and weaknesses? How are we different to others?

Who are our customers and other stakeholders? Who will want our offerings? Why us? What is our target market? Apart from customers, who else must be satisfied?

The Whyte & Brite Laundry has operated successfully for six years and now employs 73 staff. When they first started, it was just the two of them working out of Mike Whyte’s garage. Now they have a large purpose-built site with an investment of nearly a million dollars in plant and equipment and two types of customers: commercial and personal.

Personal customers are individuals who bring clothes to Whyte & Brite for cleaning and, where required, ironing. They also return to collect their clothes. Mike and his partner Barbara Brite know that the key to the personal customer business is friendly, personal service.

Commercial customers, e.g. hotels and hospitals, have large amounts of regular washing. Whyte & Brite tender for this work and the resulting contracts detail charges and service levels in relation to on-time delivery of high quality service. There is little personal contact and performance is measured on contractual terms.

Mike and Barbara had been considering a new service where they purchase the sheets, towels and other items and effectively lease them to the commercial customers.

The Whyte & Brite Laundry (see description above) has been through their strategy development exercises. They’ve produced mission and vision statements, along with strategic objectives and a strategy map that highlights strategy themes. This gives a coherent view of who they are, who their customers are, why they choose them, and what they offer each other.

They have four strategy themes:

• Customer Care Excellence
• Service Innovation
• Environmental Excellence
• Organizational Capital Development Excellence.

These four themes define their strategic intent.

A diagram I find very useful in many contexts is the organization diagram from the BPTrends Enterprise Certificate training course. This diagram, derived from the Rummler and Brache Relationship Map1, can be used in many ways and becomes a form of diagramatic repository

for strategy and process information. The example in Figure 1 shows the strategy themes for the Whyte & Brite Laundry. In this diagram the large colored box is the Whyte & Brite organizational and everything outside of the box is the external environment in which it operates.

We’ll leave Mike and Barb at Whyte & Brite Laundry, and their strategic intentions, for a moment and come back after we’ve considered the processes that will operationalize their strategy.

Figure 1: Whyte & Brite Laundry Organization Diagram

Managing Processes

As always, to be sure we are talking about the same thing, I summarize my understanding of the BPM philosophy as follows:

Business processes are the collections of cross-functional activities that deliver value to an organization’s external customers and other stakeholders. They are the only way that any organization can deliver such value. Individual functional areas cannot, by themselves, deliver value to external customers. It follows that an organization executes its strategic intent via its business processes. Business processes are the conduits through which value is exchanged between customers and the organization. Therefore, business processes need to be thoughtfully managed and continuously improved to maintain an unimpeded flow of value with customers and other stakeholders.

An organization’s resources are managed ‘vertically’ via the organization chart. Value is created, accumulated, and delivered ‘horizontally’ across that chart. Value is accumulated, not up and down the functions as represented in an organization chart, but across the organization as shown in a business process architecture. The various functions collaborate via business processes to create, accumulate, and deliver value to customers and other stakeholders in the form of a desired product, service, or some other outcome.

The organization chart is effectively silent on the all-important issue of cross-functional process work. It is quite alarming to think that in the many organizations where there is no conscious attention being paid to the management and optimization of cross-functional business processes, nobody is responsible for the creation, accumulation and delivery of value to customers and other stakeholders. This cannot be a good idea.

Starting from that perspective, the critical elements are that we discover our processes, understand how they should perform, know how they are performing, decide what performance gaps are worth closing, and take steps to affect the required closures. And repeat, forever.

The key artifact in effective process-based management is the enterprise process architecture. An enterprise process architecture is a hierarchical model of the processes of an organization. Usually created, initially at least, to include the two or three highest levels, the process architecture provides a powerful visualization and management tool. It includes not just the hierarchical description of process activities, but also the related resources, documentation, performance measures, measurement methods, and governance arrangements.

No doubt there are many ways to shape a process architecture. The way that has proven to work well for many is to distinguish management, core and support processes.

Core processes are the ones that deliver value to the customer. Management and support (sometimes called enabling) processes are there to make it possible for the core processes to work. So Define strategy is a management process, and Support staff lifecycle is a support process. Management processes are generally dealing with policy and strategy; support processes are generally about operational logistics.

Figure 2. In this diagram I have highlighted two particular support processes

At the highest level the core processes are represented by one or more value chains. The value chains represent the value propositions offered by the organization to its customers. Hence the Whyte & Brite process architecture is as shown in because of their relevance to the strategy themes – more on that soon.

The multi-layer process architecture shows all of the processes by which Whyte & Brite delivers value to all of its customers and other stakeholders. Along with process performance measures, measurement methods, and an effective way to respond to performance anomalies, the process architecture addresses the alarming circumstance in the traditional functional model where nobody is in charge of tracking value delivery.

Strategy + Process

Figure 3 closes the loop and shows how the key processes operationalize the strategy. The link between high level processes (and their many sub-processes) and the key elements of the organization’s strategic intent facilitates a clear view of how the strategy is executed. Particular initiatives related to the strategy can now be seen as changes to the related processes. Measurement and management of process performance tracks the execution of the strategy. 

Figure 3. Strategy Themes + Processes

In Practice…

There are many things you might do in response to the issues discussed in this Column. Here are four practical steps you might consider doing now to get started on the creation of sustainable process-based management.

Clarify Strategy

Clarify the organization strategy making sure there is a shared understanding. Can you clearly and consistently answer the three key questions? Who are we? Who are our customers and other stakeholders? What do we expect of each other? Identify the strategy themes and capture them in an organization diagram.

Develop an Enterprise Process Architecture

Define the processes that create, accumulate and deliver value to your customers and other stakeholders. Understand and document the customer value propositions allowing the definition of core value chains. Link the value chains to the strategy themes. Decompose the value chains to at least one more level.

Measure the Processes

If we don’t measure we can’t manage, and we can’t know if we are improving. Determine process performance measures for the value chains and level 1 processes. If these processes were working to the level that the key stakeholders would like, what would they be doing and how would you know?

Manage the Processes

We create, accumulate and deliver value to customers across the organization chart. Products and services are developed and delivered ‘horizontally’ via the collaboration of departments and teams. The organization chart is entirely silent on the critical issue management of cross-functional process activity. Appoint Process Owners to be accountable for responding when the process performance is outside of an acceptable range or trending in that direction.

SOURCE: The Leonardo Blog

Lean and the Corporate Agenda with Guest Jacob Stoller

Startup guide: Don't be afraid to give your strategic goals a tuneup

I was sitting in the conference room the other day with my computer and sketchbook, working on a new client's user interaction strategy when one of my business partners, a longtime friend, came in with this look on his face that I would describe as semi-concerned. He closed the door behind him and slumped into the chair as though his knees had given way and sat there in silence. Giving him one minute, I finally asked him just to lay it out there -- whatever was on his mind, spill it.

"I think we are losing focus," he said.

When he comes to me looking like this, I usually chuckle a bit and try to turn whatever he's concerned about around to something constructive or positive. (He does the same for me.) But this time, my face must have given me away, because as I choked out a laugh his look of concern turned to alarm. Although I could not put my finger on what had been nagging me for the last few days, I now realized that I also was worried we were losing focus -- despite many outward signs of success.

What my astute business partner had realized was that our corporate messaging was saying one thing, yet what our new clients needed was something a little closer to the ground.

The fact is, our business is starting to take off and we are all working on several projects at once. We are growing in team size, so we are taking in resumes and vetting candidates. We are in the process of packing up our small office to move to a larger location near Midtown Memphis. And we are in the process of finalizing our branding and messaging for the upcoming launch. Everything seems to be on track.

So what was this nagging feeling all about? Our realization was that we had lost sight of the proverbial forest in our race through the trees. In this case, we started to realize that with the load of projects we were working, it had been weeks since we had talked about our company's strategic goals.

Recalibrating strategic goals to bridge current and future objectives

As is often the case with startups, strategic goals and objectives will change based on reasons such as changes in technology, desires and directions of customers' needs -- or just a shift in the end-game vision itself. For us, our long-term strategic goals were to provide our customers with a host of offerings that effect a total digital transformation. Yet with our current and growing client list, we were not landing the larger jobs that fit in to this end-state. Instead, we were working on many tactical projects related to Web presence redesign and re-definition (modernization) and customer engagement. What my astute business partner had realized was that our corporate messaging was saying one thing, yet what our new clients needed was something a little closer to the ground.

So now we had to figure out how the trees would once again become a forest. We grabbed some dry erase markers and started listing out our long-term strategy and goals. We gathered our other partners and had a powwow to ensure that we were still on the same page and understood what each person's areas of responsibility were; we reviewed the associated objectives and goal assignments required to hit our company's success targets.

We have now readjusted our corporate messaging to not only resonate with our customer base and their current tactical needs but also to show them how these current solutions are the foundation for the larger strategic transformations we outlined in our company's original long-term goals.

The six-month itch

Here's the reality: In every startup, somewhere around the four-to-six-month mark, most of the strategic goals you've so carefully defined have given way to the tactical activities of constructing the business. If you'll permit me to change metaphors, let's leave the woodlands for the moment. A brick house is made of individually laid bricks. At some point, you have to leave the architectural diagram on the table and start building it brick by brick. For most businesses, that usually entails acquiring smaller clients and projects and working in an all-hands-on-deck manner to deliver on commitments. As time goes on, the small projects grow in size, as does your team and your company.

So, by all means, focus on the daily grind of building your business. But be aware that the tactical grind when left unchecked can lead to a significant departure from the original corporate plan of your business. This is not necessarily a bad thing, as sometimes, the ability to adapt can bring something new and unexpected strategic goals that could be better than what was originally designed. Conversely, going back to the brick building, you could also end up with one wall ten feet higher than the other with no way of joining the two. By implementing some general process controls, you can ensure that the strategic vision (forest) is not being obscured by the tactical (trees). Try having weekly partner meetings or displaying the company's definition of success in the break room -- by the beer. Cheers!

SOURCE: SearchCIO