<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

Think First—Why Process Mindset Must be Developed Early

Roger Tregear Roger Tregear on April 3, 2018

Think_Early_Developing_Process_Mindset.pngToo many BPM initiatives fail. We’ve got to do better.

In this article, I discuss an important area where considerable improvement can be realized.

Process-based management is not achieved and sustained by having the right software and methods, indeed you can probably make it work well with the wrong software and methods. Done properly, process-based management is a systemic approach to the relentless pursuit of organizational performance improvement. It’s largely a mind game. Put simply, to ‘do process’, an organization, its people, and their teams need to ‘think process’.

In a process-centric organization, all employees are conscious that their roles are to participate in executing a range of processes. They think beyond the activities described in their own job descriptions to see their roles in the bigger picture of creating, accumulating, and delivering value to customers and other stakeholders via cross-functional processes. Yes, that is a big change.

The unrelenting emphasis is on conscious, cross-functional collaboration—and that is often challenging for individuals and functional units in an organization.

Achievement of effective, sustained, process-based management is ninety per cent mindset and ten per cent toolset. Too often, the focus is on the ten per cent at the expense of the ninety per cent. Tools, including software, systems, methods, and techniques, are critically important—the full one hundred per cent is needed—but the tools are not the main game.

Having the right tools is necessary but nowhere near sufficient for success. It might be argued that the mindset/toolset emphasis is 80/20, or perhaps even 70/30, rather than 90/10, but it’s certainly not the reverse of any of those. Tools and techniques alone won’t create a viral spread of the idea of process-based management. Hearts and minds are also needed.

To have any value, process-based management must support achievement of organizational objectives.

Success is not measured by the number of models drawn, the cleverness of a process architecture, the number of process measures identified, or the sophistication of automation. Success can only be claimed if organizational performance has been demonstrably improved as a result of taking a process view. The process mindset must be about achieving those consequences of effective process management and improvement; that is, it must be about improving organizational performance.

Success is not measured by the number of models drawn, the cleverness of a process architecture, the number of process measures identified, or the sophistication of automation.

Having the process-based management idea resonate throughout an organization provides a shared mindset with which to build its practices.

The likelihood that organizations, teams, or individuals will adopt process-centric management approaches depends on what they think will happen if they do. When everyone is conscious of their contribution to the cross-functional processes that are delivering value, the result is process management excellence. The process mindset is not about attracting devotees to a theory, but about creating and sustaining change in the way work is designed, undertaken, and managed across the organization.

The practical application of process-based management needs to take systemic form. It may not be enough to declare a commitment to ‘operational excellence’, since that might just imply working harder to keep poorly designed processes operational. ‘Excellence’ needs to be found in a ubiquitous desire to continually find ways to improve performance—not just in a continuous, heroic struggle to correct for process flaws.

Ironically, at the highest levels of BPM maturity, the practices of process-based management are so embedded in the culture, and so ubiquitous in practice, that they are virtually unseen. At the lowest levels of maturity, the idea of process does not even arise. As maturity develops, driven by the development of all seven enablers, individuals, and then teams, start to think about cross-functional processes.

Eventually those thoughts result in practical activities to shape and nurture process thinking. Over time, the application of process-based management becomes automatic and the classic definition of organizational culture, ‘the way we do things around here’, once more proves accurate.

Passively waiting for the happy day when everyone is ready is clearly not a winning strategy.

Timing is everything. An organization must be ready to start, and continue, a journey to process-based management, a change that is as much about organizational culture as it is about the logistics of process management and improvement.

Passively waiting for the happy day when everyone is ready is clearly not a winning strategy. Neither is the development of a process mindset a Jedi mind trick, something that just requires the exercise of a greater and more powerful will.

A deliberate, well-designed plan is required to develop an organization’s process mindset, that is, its cultural readiness for process-based management. The ongoing results of such a plan need to be measurable.

Defining the process mindset

Minds are often hard to change, but it can be done. Once changed, minds are likely to stay changed for the same reason.

A process-aware organizational mindset will have a particular, and sometimes challenging, set of characteristics. It will be:

  • measurement-friendly
  • community-focused
  • quality-motivated
  • change-welcoming
  • challenge-addicted
  • action-oriented.

Each of these is important.

The most challenging of the organizational characteristics might be an openness to performance measurement. One of the most significant roadblocks to robust and sustainable process improvement and management can be the absence of a measurement-friendly culture.

Where measurement is about finding someone to blame, catching people doing the ‘wrong thing’, then nobody will be pleased about the idea of additional measures. Acceptance of measurement as an exciting pathway to performance improvement must evolve for process-based management to succeed.

People and their teams who work with a highly-developed process mindset are constantly aware of the community effort involved in the creation, accumulation, and delivery of value to customers and other stakeholders. It’s not just about ‘my job’; it’s about ‘our job’ and how all involved collaborate to do the right work well.

A relentless drive to improve and produce quality outcomes is a key attribute of the process mindset. The search to find ‘better ways’ is never-ending, and the motivation to continuously improve quality is deeply embedded in the organizational culture.

Continuous process improvement means continuous change and, from time to time, significant change that poses challenges for the organization, its people, and their teams. The process mindset is uncomfortable in a static environment.

Well-designed, controlled action is required to realize the benefits.

Process improvement is not about making recommendations; it’s about making change. Well-designed, controlled action is required to realize the benefits.

In an organization with a well-developed process mindset, the following comments would be unremarkable:

  • It’s OK to make mistakes; we welcome the opportunity to learn and improve.
  • All questions are welcome and the organization is open to new ideas; we are willing to experiment.
  • People at all levels are listened to, and we have open discussions about new and contentious ideas; we welcome dissent.
  • We have a strong collaborative ethos without silos and turf wars; we strive for excellence by being collegiate and customer-focused.

The absence of a process mindset at the organizational level is the difference between ad hoc attempts at process improvement, and the sustained operation of a systematic approach that deliberately and continuously discovers opportunities for process improvement, an approach that is embedded in the organizational culture.

At the level of the individual, creating a process mindset is not necessarily about correcting some defect in staff motivation. The fact that poorly designed and/or managed processes work at all might be because of very high levels of motivation.

In many cases, staff need to be highly motivated to find the work-arounds and put in the extra effort required to make processes work. So, to say that an organization needs to develop the process mindset of its staff is not to be critical of them. It means that the way work is described, measured, and managed needs to change, and that staff need to be made aware of, and fully included in, the collaboration that creates value. Staff need to receive the training and experiences that will allow them to work effectively in an organization with a well-developed process mindset.

Practical tips for changing minds

Many practical strategies can be employed to develop the ‘process mindset’. Some of these include:

  1. regular ‘community of interest’ meetings
  2. process-improvement project discussion groups
  3. library of process information
  4. process innovation jams
  5. documented success stories
  6. open discussion of process performance results
  7. idea submission schemes
  8. recognition of individual and team excellence.

Training will also be necessary in topics such as:

  1. effective communication
  2. lateral thinking
  3. dealing with difficult people
  4. teamwork
  5. conflict resolution
  6. system thinking
  7. innovation.

A process-aware organizational culture and mindset can evolve through active leadership and development plans, paving the way for successful and sustained process-based management.

The target is to employ such development strategies to achieve a tipping point beyond which process thinking is the norm, to trigger the viral spread of the process idea, shaped and made relevant to the organization.

How does this Process-based management idea help to make life a little, or a lot, simpler and easier in day-to-day work? Those messages must be tailored to resonate with the different stakeholder groups. Everybody needs to see for themselves the practical meaning and purpose in the theory and practice of process-based management.

Changing minds is not a one-off project, nor a single series of time-limited activities. Continuous reinforcement is required to remind everyone why process thinking is important, and to validate the assertion that genuine and worthwhile benefits are accumulating.

If we are to improve our hit rate in achieving and sustaining effective process-based management, process thinking needs to be actively nurtured.

Download free chapter of Reimagining Management

Topics: BPM - Business Process Management

Putting Process at the Centre of Business Management

Roger Tregear Roger Tregear on March 14, 2018

Putting Process at the centre of business management Many organizations face the complex dilemma of dealing with major strategic and operational changes, often simultaneously. The complexity of the management challenge is increasing, often with alarming speed and consequences. This causes, not just a superabundance of operational problems, but strategic hazards that may test the viability of the organization. Key macro-challenges might include:
  • radically increased customer expectations
  • sector and business-model disruption
  • reducing costs of market entry
  • intensified competition
  • radically and rapidly changing technology
  • cost pressures
  • mounting regulatory-compliance demands
  • diminishing staff numbers
  • increasing operational complexity
  • fragile workforce enthusiasm

These are mission-critical problems and there is a growing realization that something new is needed if they are to be solved.

The organization chart shapes traditional management. Management effort consequently focuses on functional areas, i.e. ‘boxes on the chart’, and is easily fragmented. This form of ‘functional’ management has always been a key feature of management practice. Long before the invention of the theory of contemporary management in the first half of the twentieth century, organizations have structured themselves into units based on the type of work performed.

Just as clearly, to get work done, to deliver value (products and services) to customers, requires collaboration across the organization and coordinated work across the separate functional areas. Every organization creates, accumulates, and delivers value across its organizational structure. Resources are managed ‘vertically’, following the organization chart, but the value pathway is ‘horizontal’, based on cross-functional collaboration.

To take a familiar example, imagine the sequence involved in air travel. The passenger arrives, checks in, boards the plane, completes the flight, retrieves luggage, and leaves the airport. For the passenger to have a good trip, all of that must go well. No point having the world’s best check-in service if the luggage is lost. Having to find lost luggage is both annoying for the passenger and expensive for the airline.

The creation, accumulation, and delivery of value to customers is inherently cross-functional and requires collaboration across the organization, and often beyond into other organizations. This is fact, not an opinion to challenge or a point of view to contest. Management needs its own disruption, a radical departure from the traditional model.

Organizations must be good at identifying circumstances that threaten performance, but that is not enough. They also need to look for characteristics that make it strong, and for opportunities to do something new, perhaps radically innovative.

It is no longer enough, if it ever was, to focus on immediate performance issues and ignore opportunities for improvement. Henry Ford reduced the build-time for a Model T chassis from 12½ to 1½ hours—a prodigious feat, an innovation whose impact is still felt today, but it would have been pointless if no one wanted to buy a car.

In 1976, with a ninety per cent share of the US market, Eastman Kodak was ubiquitous; by the late 1990s it was struggling; by 2012 it was in bankruptcy protection. Despite having invented the digital camera in 1975, Kodak was slow to react to a serious decline in photographic film sales. At its peak, Kodak also had a great story to tell about increasing efficiency and performance improvement. It became efficient at producing a product few wanted, and good at delivering services few needed.

In times where digital substitutes overwhelm established business models, every organization must expect to have its own ‘Kodak moment’.

The primacy of process

A business process is a collection of activities that transforms one or more inputs into one or more outputs. Many resources are involved in the management and execution of a process—customers, staff, materials, systems, infrastructure, information, technology, suppliers, facilities, policies, regulations—and these must also be seen to be integral to the definition of process. Processes are vital because this is how organizations get work done.

The fundamental concept underpinning the ideas and practices described in this paper is the primacy of process. This says that business processes are the only way any organization can deliver value to customers and other stakeholders outside the organization. By themselves, the separate functional areas of an organization cannot deliver value to external parties. It follows that every organization executes its strategic intent via its business processes.

The sequence from strategy to execution is shown in Figure 1, encapsulating both the strategic and the operational importance of the process view. 

FromStrategyToExecution

The inescapable conclusion is 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 improve and strategy cannot be effectively executed.

  • If value is created, accumulated, and delivered across the organization, are those value pathways defined and documented?
  • If value is created, accumulated, and delivered across the organization, what measures of performance are made in that direction?
  • If value is created, accumulated, and delivered across the organization, who is in charge of that?

Organizations must reimagine their operations as value creation and delivery flows that must be proactively managed and continually improved. The management philosophy that facilitates that is process-based management.

Defining process-based management

Bringing together these concepts, three principles underpin process-based management:

1. Business processes are the collections of cross-functional activities that deliver value to an organization’s external customers and other stakeholders—the only way that any organization can deliver such value. Individual functional areas cannot, by them-selves, deliver value to external customers.

2. 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 thought-fully managed and continuously improved to maintain an unimpeded flow of value with customers and other stakeholders.

3. An organization’s resources are traditionally 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.

Processes__Functional_organisations

Figure 2: Functional and process organization views


The profound premise for process-based management is illustrated in Figure 2, showing both the functional and process organizational views.

Enabling process-based management

Seven elements, the 7Enablers of BPM, come together to create and sustain process-based management. If developed simultaneously at the pace appropriate to the organization, these elements significantly increase the likelihood of creating sustained process-based management.

The 7Enablers is a collective of mutually supportive prerequisites for successful and sustained process-based management.

  • Process architecture: discovery, understanding, and documentation of the organization’s business processes and related resources in a hierarchical model.
  • Process measurement: defining process performance measures and measurement methods, collecting and reporting process performance data.
  • Process governance: reimagining, and responding to, process performance anomalies, innovation opportunities, process documentation, and general hygiene.
  • Process change: continually discovering ways to close process performance gaps by eliminating problems and capitalizing on opportunities.
  • Process mindset: creating an environment where the organization, its people, and their teams, are always conscious of the processes in which they participate.
  • Process capability: developing the tools and skills required throughout the organization to identify, analyze, improve, innovate, and manage business processes.
  • Process support: providing support throughout the organization to develop, sustain, and realize process-based management benefits.
15-Mobious7EnablersLOGO_03 

Figure 3: The 7Enablers of BPM

These seven enablers are shown in Figure 3. A Mobius strip format is used to highlight the interdependencies between the elements.

To thrive, perhaps even to survive, in times when ‘doing more with less’ seems both inevitable and impossible, executives need to reimagine their organizations as value-creation and delivery flows. Process-based management delivers a practical, proven approach and the 7Enablers represents a breakthrough in management practice.

Managing reimagination

This paper has discussed seven enablers of process-based management, seven elements that will put management focus where it should be, on cross-functional value creation, accumulation, and delivery. If you accept the premise that no unit identified on an organization chart can, by itself, deliver value to an external customer or other stakeholder, (and how could you not do so?) then you accept the main concept of process-based management. The inevitable consequence of that is acceptance of the certainty that processes must be identified, analyzed, improved and managed. Since the organization chart is silent on the management of cross-functional processes, a separate, targeted, and comprehensive intervention is required to enable process-based management and realize the benefits that come from it.

At a time when the requirement to ‘do more with less’ seems both inevitable and impossible, process-based management delivers a practical, proven approach.

This article is an edited extract from the book, Reimagining Management. From the foreword by Professor Michael Rosemann: ‘This book has the potential to become an essential, shared point of reference for designing organizations.’

 DOWNLOAD CHAPTER 1 OF REIMAGINING MANAGEMENT

 

Topics: BPM - Business Process Management

Creating Value in Customer Experience Management

Indrajit Datta Chaudhuri Indrajit Datta Chaudhuri on March 8, 2018

CXM-process-perspective.png

An organisation should be looking for ways to continually add value.At it's core Customer Experience Management understands what is of value for a customer, and how we create/deliver value, that will lead to actions that result in a good customer experience.

Value, in simple terms, is when the business offering meets the customer needs.

Defining ‘value’

Value is usefulness; value is utility; value is a problem solved. Value feels good.

Organisations constantly try to add value for their customers. In the past, there has been a siloed approach to adding this value. Each department put in an effort and attempted to give their best, only to find out that individual best does not necessarily lead to a holistic best, as sometimes the department’s direction is in conflict with others. A customer gets a good product and service when all the participants attempt to make the interaction value-added for the customer (not just the customer facing).

You may think that there is nothing new in this, and this is what people have always attempted. Every process-design effort undertaken in organisations has tried to achieve exactly that.

The key difference is that here we don’t need a stakeholder priority matrix to identify who to impress and who not to. The stakeholder is pre-identified—it’s the customer. The moment we say that every participant in the process is a customer, we are losing focus.

Here is where ‘product/service view’ comes into play. The following section is an attempt to reconcile the process and product/service views, and how that approach helps shift the focus from internal process participants to the customer.

Reconciling product/service, process and experience

Dr Michael Roseman, in his article Process management as service (2010), gave a very good description of process and service:

Process’ and ‘Service’ are complementary views on the same capability of an organization. As two distinct ‘sensitizing devices’, however, their associated viewpoints stress alternative facets of organizational capabilities. A process view sharpens the understanding for the operational model of a capability. It provides the required analytical foundation to reflect on the current and potential future performance of a capability as far as this performance can be impacted by the way it is delivered. As such, a process view can be seen as an approach to ‘white box a corporate capability’.

In contrast, a service-oriented (external) view on a corporate capability can be regarded as a ‘black box’ perspective. The emphasis is, as described above, on the conscious abstraction of the internal operations of this capability. Instead, the focus is on the overall value proposition (what can the service provide?), the related costs, the underlying governance model (‘what happens when the service fails, i.e., service continue management’), and further non-functional service properties as part of a service level agreement (response time, quality standards, etc.).

It is important to have a service (and/or product) view, because that is what the customer is ultimately consuming; the processes remain the mechanisms to deliver the service (and/or product).

For example: In a salon, the haircut is a service: take a ticket, wait, get a haircut and then pay for the haircut (make payment) is the process. The combination of a quick cut, easy payment and a nice hairstyling that gets you positive attention by your friends is good customer experience.

Product/Service is about benefits.

Process is about the mechanism to deliver a product/service. Experience is about the overall feeling that the customer has about the interaction.

Framework

Considering a customer as a single entity in a process design implies that all customers can be treated in exactly the same way. However, representing all customers in a similar manner oversimplifies and generalises the needs of the specific categories of customers. Customers with similar needs can be categorised together, and processes can be designed to cater for these different categories. These customer categories with similar needs can be called ‘persona’.

The following diagram depicts the perspective of aligning customer needs with the business offerings.

CXM-Value_Creation.png

Figure 1: Value creation and delivery approach

This diagram has two sections. The top section is where an individual customer is considered from the point of view of his/her needs. Patterns are matched and customer personas are generated, and these represent a group of customers with similar needs. These needs of the various personas are the needs that, when satisfied, creates value.

The other perspective is the organisation view, where the business goals are delivered through execution of business processes. Business processes produce outcome; they deliver products and services while catering to the needs of the customers represented by the personas. The value zone represents the interface where needs are fulfilled, and the customer gets a good overall experience.

We are aligning what the business has to offer with what the customer needs. Needs that have two components: the stated needs, and the unstated needs. Good customer experience is the combined effect of fulfilling both needs.

CXM-Components_of_CXM.png

Figure 2: Components of customer experience

To ensure the end user is in focus, we need to take a product/service view as well a process view. A product/service view ensures that the end-user needs are in focus, and a process view acknowledges that the outcome is a combined effect of multiple activities that span across the individual organisation entities.

Download Customer Experience Management Paper

Topics: BPM - Business Process Management, CXM

Driving a Repeatable Robust Model of Integration

Adam Mutton Adam Mutton on February 27, 2018

 

Integration efforts are frequently suppressed by the high cost of latent resources, slow delivery models, expensive licensing alongside the battle of retaining the capability of staff year on year. The maturity of open source combined with advancements in cloud technologies presents great opportunities to realise the potential of a scalable, subscription based integration to meet business challenges & drive business transformation.

Below is a transcription from the presentation by Adam Mutton at the Red Hat Forum in Sydney, October 2017. 

--

 

The maturity of open source, combined with advancements in cloud technologies has presented a great opportunity to realise the potential of a scalable subscription-based integration model that meets business challenges and drives business transformation. I'm here today to talk to you about the direction Leonardo was seeing integration heading in, and how we see it driving towards a replicable, repeatable, and robust model of integration, and what kinds of tools and services that are required to make that a reality. 
Leonardo have been in the IT industry for almost 20 years and until recently, has been well known for high-end BPM consulting. However, in the last few years, Leonardo identified a need to connect business process improvement with actual execution.

To achieve this, we assembled what we believe is some of the best integration people in the industry and extended our capability to include the delivery of automation and integration solutions, or what we're calling the Leonardo stack. This is the connection between BPM automation and integration - the connected view of the organisation that allows us to take a slice of your business processes and improve them gradually over time.

So, what's the thing we're hearing from our clients about that they want to achieve - but they can't quite put their finger on what it is they want to do?

What we at Leonardo is seeing is a paradigm shift in the market towards a sustainable full business integration.

What it isn't

Before I go on and explain what we think that means, let me tell you what it's not.

RedHat_Forum2017-34.png

1. It's not expensive perpetual software licenses

It's not expensive perpetual licences - or as we call it sticker shock.

I'm sure you've all worked on projects that have spent millions of dollars on hardware and software. You've expended effort in getting the teams together, getting everything ready to go, all before you've ever cut one line of code.

RedHat_Forum2017-33.png
2. It's not multiple vendors and integrators

It's typically involving multiple vendors supplying various parts of the solution, software, hardware, services, support, all usually working independently of each another and not very cohesively. If you've done large transformation projects before, you'll know what I'm talking about.

RedHat_Forum2017-32.png

3. It's not slow delivery models

All delivery models have their place. However if we're thinking of innovative ways about how you improve your business, we need to think about new ways of delivering those projects.
RedHat_Forum2017-31.png
4. It's not monolithic ESB implementations

The modern two-speed deployment model, it still needs a ESB to play I'ts role. However, when we talk about agility, time to market, code management to deployment, the monolithic ESB is not the way to achieve this.
RedHat_Forum2017-30.png
5. It's not maintaining high-cost specialist in-house resources

What it's not is not maintaining a capability in-house in order to keep the lights on.
Reactive behaviour to business requests is costly and inefficient. The days of the in-house chin rubbing ( as I call them) ICC people are dead. Business are done dealing with the key man syndrome (retaining people around just because of their special skills). The staff themselves, they want to be more innovative and more engaged.


So, what do our clients telling us?

RedHat_Forum2017-29.png
1. Don't want to be stuck in waterfall centric multi-year transformation projects

Well, what they're telling us is that they don't want to be stuck in huge big bang projects anymore. They are too costly and usually don't deliver on their promises. If you ever been at restaurant, you would send back the dish saying "This is not the steak I ordered…." .
RedHat_Forum2017-28.png
2. Don't want wasteful dead-time development

What they're telling us is that they don't want to have teams of people sitting around, waiting for requirements, or even waiting for hardware / software to become available. This is dead time in the delivery world. I'm a crusty old project manager and I know how dead time can be a project management killer. Clients don't want to warehouse their people anymore for the specific skills. What they want, and what they should be able to get is that these skills should be on demand when they want them.
RedHat_Forum2017-27.png
3. Don't want costly upgrade cycles

What that telling us is that they're overpaying massive upgrade fees, licences and services just to maintain technical currency. This locks them into a non-negotiable position with their vendor and specialised staff. This is not the way to be an agile organisation.
RedHat_Forum2017-26.png
4. Don't want to create situation of vendor conflict AND change ransom request

On top of all of this, what we're finding is that clients find themselves inmanagement ransom. They want to get away from having to worry about technology, and they want to get on with what they do best.

We all know what Coca-Cola is, right

Let Coke market and sell Coke. That's what they're good at. IThey shouldn't have to worry about the technology. The technology should just be the thing that helps makes their core business happen. Business and technology should be seamless.


What our clients are asking us to help them with

We talked to our clients - they told us their thinking, their pain and what they want to achieve, and this opened a dialogue about how we can help them
RedHat_Forum2017-25.png
1. Help them get off fluctuating cycle of ramp up and ramp down.
They said they want to get off that wave - the up and down wave - of work versus resources, new work versus upgrades.

It's the old problem. You've got too many people on the bench and not enough work, or too much work and not enough people, or you want to get new work done but you need an upgrade because the feature is not available, or you have all these things in place but you're out of currency. These are all problems that just kill you. It's unsustainable, it's not reliable, and it's costly.
RedHat_Forum2017-24.png
2. Help them change culture from reaction to innovation
They told us that they want to be innovative and they want to get ahead of the curve. They don't just want to be reactive to the business. They want to be able to commit to quick turnaround times.

They want to be able to achieve business agility. The want to raise the level of the staff satisfaction. Stop people walking out the door because they aren't challenged working here and want to do more innovative things. Clients want to make it exciting for staff to come to work.
RedHat_Forum2017-23.png
3. Help them become focused on business not IT
The business wants to do what they do well and not be hampered by IT - remember what I said about Coke? It should be holistic - not IT for IT sake….
RedHat_Forum2017-22.png
4. Help them do full business integration
What we're talking about is connecting across the whole business. We believe it's time that integration was redefined. Integration is connection.

The connection of things is about bringing all areas of business and IT together in order to achieve a positive outcome for the business. It should be everyone working together.
RedHat_Forum2017-21.png
5. Help deliver pay as you go business models
Clients are telling us they want to pay as they go and see immediate value. They want to get away from the huge licence fees, big service fees, and big transformation projects. By paying as you go and what we've seen so far - is that you can show you value to the business and get better stakeholder buy in. Then clients can do the next step, and then the next step. What this does is enables the continual improvement cycle.
RedHat_Forum2017-20.png
6. Help deliver a manage capability and services model
What clients are telling us is that they want to manage service. This managed service would provide a high-end capability with dynamic availability. They want a model that enables business agility through CI-CD, DevOps and Agile. They also want to reduce total cost of ownership.


What does sustainable integration look like?

It's some form of a flexible managed service that has the following features:

RedHat_Forum2017-19.png

  • It's subscription-based.
RedHat_Forum2017-18.png
  • It encompasses technology plus delivery.
    • The two must go hand in hand.
RedHat_Forum2017-17.png
  • It has microservices, CI-CD, APIs, DevOps, Agile.
    • The technology all developers love diving into.
RedHat_Forum2017-16.png
RedHat_Forum2017-15.png
  • It's cloud-based
RedHat_Forum2017-14.png
  • It allows you to develop and deploy microservices.
    • More and more we see benefits and necessity of microservices and the ability to turn projects around quickly and provide value back to the client.
RedHat_Forum2017-13.png
  • All underpinned by a source code management process that ensures code quality and speed to deployment.
    • Think Google, Facebook, and now, AWS and IAG. Until the keynote today until today, I wasn't aware at how quickly companies like this were turning these things around. I would never thought of seconds or minutes in terms of deployment. I would have thought every hour or so.
    • Developers today want to deploy and test rapidly. If it doesn't work, they'll take it down. But they don't have to redeploy huge volumes anymore and deal with massive downtime.
    • Perhaps you should think about how source code management could benefit your organisation today. The speed at which business can react to market movements makes me evaluate everything - perhaps you should be to.
RedHat_Forum2017-12.png

  • It's specialist capability on demand.
    • In other words, clients and our clients don't have to carry a bench anymore. They don't have to worry about warehousing staff for the skills. It's on demand as required. Think of it as a virtual bench that you can draw on. This in itself cuts a huge waste out of any development and deployment that you're doing. Huge benefits to be gained.


Leonardo's connected stack

RedHat_Forum2017-LCstack.png

This helps us achieve & deliver all the elements above by connecting the process lifecycle, building confidence with our stakeholders, aligning business and IT, lowering total cost of ownership, driving continuous process improvement, and enabling business agility and digital readiness.


Why Red Hat?

RedHat_Forum2017-2a.png

Portfolio of enterprise grade support technologies

The question gets asked, why Red Hat?

Red Hat have portfolio products that make this all possible for us.

In Red Hat OpenShift, you've got your concept, containerization, self-healing, scalability - no more heavyweight VMs to contend with. Red Hat JBoss Fuse delivers enterprise lightweight ESB solutions. Red Hat 3Scale gives you API management. Red Hat JBoss BPMS gives you automation and workflow engine. This is complimented by other tools such as Red Hat Ansible, Red Hat Data Virtualization, Red Hat BRMS.

You have the ability to integrate with other best Red Hat technologies as well which is a key factor here. There are other open source projects going on all the time and you always got the ability either to integrate with them or you can go to a vendor specific product in the marketplace as well. So, it gives you flexibility and ability to innovate.
RedHat_Forum2017-5.png
Open Source Minded

Red Hat, they're open source-minded. They are one of the key pioneers of open source. Open source gives us diversity and flexibility. It gives us vendor choice. You're not just locked into one vendor. Importantly, it gives you the innovation that comes from the open source community which gives a great benefit to everyone.
RedHat_Forum2017-4.png
Subscription Based

At it's core, Red Hat is subscription-based. More and more situations with our clients, they rather go to subscription-based model than the big licence fee.
RedHat_Forum2017-3.png
Enables Continuous Improvement

The Red Hat product suite is what enables us to actually deliver continuous improvement and the new fully connected integrated business.

Where is all this heading?

As I mentioned previously at Leonardo, we have seen a bit of a paradigm shift in the market towards a full stack managed service of business and IT that enables business agility and process improvement. We have the knowledge. We have the know-how and we have the technology to make that happens seamlessly for the client. We achieve this via the Leonardo connected stack and managed services - all powered by Red Hat. We're actually delivering benefits to businesses today.

RedHat_Forum2017-1.png

To return to the original question - 'Is a replicable, repeatable, and robust model of integration delivery possible?

The answer, we believe, is yes.

It is possible for a full business integration via the Leonardo stack.

This gives you a robust model of integration delivery.

 

Sign Up for Our BPM Automation Integration Workshop

Topics: Intergration, redhat

Customised Model Release Cycle Management in ARIS

Sam Nguyen Sam Nguyen on February 22, 2018

 Custom_Model_Release_Cycle-Management_ARISSince the first release of ARIS Connect, the concepts of publishing in ARIS have changed and lightweight workflows were introduced to provide basic support for the governance of process models. These new features have brought new and interesting experiences.

However, feedback from ARIS customers with unique needs for rigorous process model governance indicated that more is needed than the lightweight workflows—like, for example, a workflow for publishing models in isolated repositories to ensure consistency for reporting and analysis.

Although the gap left by the lightweight workflows can be filled by a fully-fledged ARIS Process Governance engine, budgets are often a barrier. On the other hand, manual administration (e.g. the handling of models across several repositories without the support of automation) requires a fair bit of maintenance.

Solution Overview

To address these challenges, a customised approach is proposed; and this article introduces a semi-automated solution through the programming and reporting capabilities in ARIS.

Custom_Model_Release_Cycle-Management_ARIS_Elements

 

Figure 1 – Elements of Customised Model Release Cycle Management

 

The solution includes a few elements as described in Figure 1. There are four different roles that are responsible for advancing a semi-automated workflow through the invocation of designated Release Cycle Management (RCM) reports. These roles are designed for a typical scenario, and can be changed and updated according to a customer’s specific requirements.

Two repositories are used: one for housing, developing, reviewing and approving process models; and another for the released process models. The latter, the production repository, is available for operational users to consume models once released and transferred from the development repository. It is also available to process approvers to review feedback for revision should changes emerge in the process context.

A set of reports carry out actual RCM tasks, and inform the relevant roles with support from an internal email system. A set of records is logged in raw format every time a model status is changed for potential later reporting. This logged information includes: date/time, the RCM task performed, and process model information, etc.

Transitions of model status

The model status, which is identified by a model attribute, is essential to determine the status of process models in the release cycle. It is also the basis for the RCM tasks to carry out appropriate activities, inform relevant roles, and determine the next status.

Custom_Model_Release_Cycle-Management_ARIS_Merge

 

Figure 2 – Transitions of model status

Model status is set to “In Progress” as soon as a new model is created. Once the model is ready for review by an appropriate reviewer, the modeller runs the RCM task “RCM – Request Model Review”. The task changes the model status to “To be reviewed”, and sends an email to the reviewer.

The model is then reviewed and, if the model needs more attention, the reviewer rejects it by running the RCM task “RCM – Reject Model”. The model status is then changed back to “In Progress” and an email is sent to the modeller with relevant comments.

Alternatively, if the model review was successful, the reviewer runs the RCM task “RCM – Request Model Approval”. The model status then changes to “Reviewed”.

Custom_Model_Release_Cycle-Management_ARIS_Tr

 

Figure 3 – Implicit merge of released models

The process owner is now triggered by an email sent by the RCM task to perform the last review. The model can be rejected by the owner, or released to the production repository. The process owner, therefore, can run both RCM tasks: RCM – Reject Model or RCM – Release Model. In the latter case, the RCM task changes the model status to “Released”, locks the model in the development repository, and implicitly merges the model to the production repository. The production repository will have the same structure as the development repository and houses only released models.

The status “To be revised” is set when process owner has received feedback from operational users, or other parties, about certain defects in the process. As operational users are viewers in ARIS Connect, it is possible to inform the process owner by commenting on the model within ARIS Connect. The process owner then evaluates the feedback, and is able to run the RCM task RCM – Request Model Revision if the process needs to be revised.

From this point, further work is carried out to formalise a solution to address the reported feedback. Once the concerning model has been updated with the agreed changes, the process owner runs the RCM task RCM – Request Model Update. The model is then unlocked, and the model status changes to “In Progress”. Relevant parties receive emails about the changes, which starts a new RCM cycle.

Solution Summary

This RCM solution offers a practical and flexible approach at a reasonable cost—reasonable, that is, compared to the investment that comes with the introduction of APG.

As the automation is implemented by ARIS reports, it is possible to call these reports from both THICK and THIN clients (even by ARIS Connect viewer users), which means that all types of client are able to participate in the RCM activities if required.

This flexibility of programming also allows custom semantic checks to be incorporated in case in-built semantic checks fail to meet requirements. This pragmatic approach for semantic checks allows them to be connected to certain RCM stages. As it is a customised solution, it can be adapted to future changes.

The solution supports the participation of operational users to feedback from the context in which the processes run. Normal RCM solutions are encapsulated in a BPM Office.

Although ARIS Connect is used in this sample scenario, the solution can be adapted to support a combination of ARIS Design Server and ARIS Publisher with similar results.

ARIS Customised Reporting 

 

Topics: BPM/EA Technology, BPM - Business Process Management