Systems Thinking

Building processes that work, is quite a straightforward task, we can take out our pens, and sit and record how it works, but building processes that reduce waste is a whole different ball game.

What Exactly is Waste?
The simplest way to describe waste is as “Something that adds no Value.”  Would you be happy if you received a bill in a restaurant that included a meal that was prepared in error? No; you would argue and demand that it was removed from your bill; yet if you buy a product in a store the price that you pay will contain costs that you would not want to pay. Would you want to pay for the machine operators wages whilst they sat idle waiting for a delivery, or for the rework processes that had to be undertaken because the machine was incorrectly set, or even for storing your product for three months before it was delivered to the store? These wastes are included within the cost of your products, either inflating the price you pay or reducing the profit of the company.

Why Remove Waste?
Profit is your selling price less your costs, no matter how you think about the selling price it is very much dictated by the market not by yourself. If you charge too much then your customers will go elsewhere, even if you charge too little you may lose customers as they will perceive there may be something wrong with what you are offering. Therefore the only way you have to improve your profits are to reduce your costs; this means removing all elements of waste from your processes.

In addition to improving profits you will find that waste has a major impact on your customer’s satisfaction with your products and services. Customers want on time delivery, perfect quality and at the right price.

We have built business here in the Western World based on a Financial model including Departments, Budgets and a Project & Programme Managers to keep technology builds on budget and on time, leading a Sequential Development, or the Waterfall methodology..

Agile is a term used to describe a general approach to software development. All agile methods, including Scrum, emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change.

Where Did Agile Come From?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticised sequential development. He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialised groups that complete each phase of work.

It’s easy to see how the “waterfall” methodology is far from optimised compared to agile methodology. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?
Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

As businesses we are always striving to be better, meet customer’s ever-rising demands, and remain competitive. There are many methods, practices, and philosophies in which they engage to achieve this (Innovation Management, Continuous Improvement, Lean Management, 6-sigma etc.), and organizations invest heavily in tools and consultants to implement these effectively.

One of the often overlooked methodologies is BPM (Business Process Management). Organizations, when asked, will normally state that they feel their processes are under control, but if asked how they make sure they are constantly improved and modified to meet changing needs; their answers get a little blurry.

It turns out; most organizations do improve their business processes, but usually as a reaction to a problem. Even though they engage in some of the above mentioned improvement methodologies, they are usually product and service centric, and not Business Process centric. They lack the tools and culture to proactively engage in Business Process improvement like they would in their manufacturing and service delivery processes.

If we follow the WikiPedia definition for BPM (Business process management is a holistic management approach focused on aligning all aspects of an organization with the wants and needs of clients), we realize that Business Processes actually govern all other processes engaged in by organizations. We actually need business processes to accomplish all other processes in the business cycle.

Most organizations will have tools and procedures to enable their team members to identify and execute on improvement opportunities in their products and services. This is because of tangible gains (normally reflected in the bottom line) to be had with the execution of improvements. The tools used will ensure the improvement is captured (process flows, instructions and standards are updated in central repositories), communicated, and translated to the bottom line. The tools and processes used ensure teams impacted upstream and downstream are in-the-loop.

However, organizations seldom invest in tools and expertise to effectively manage and improve their business processes. A major reason for this is that they do not look at business processes as being equal to, or more important than a manufacturing process.

The benefits of improving these don’t automatically translate to the bottom line, and thus organizations usually do not take a proactive approach to improvement. Problems with poor business processes are usually reflected in wasted time (usually made up by employees working overtime), and are normally not addressed unless they have an adverse and measurable effect on the bottom line – sometimes leading to a real line-stoppage (i.e.: someone did not place an order for parts using the ‘new process’).

These types of line-stopping (and consequently very expensive) events are usually a result of not having well defined standards and procedures to manage the business process lifecycle. This can be quickly identified by two critical missing elements:

a) Business Process Maps:
Just like a manufacturing process flow-chart maps the flow of material and value-add activities at each station in the process, the Business Process Map shows the flow of objects (Usually Information) and activities performed at each step. There are specific sets of instructions, standards, documents, roles and resources related to each process step. The business process map becomes the standard baseline from which change can be made.

The result of not having Process Maps can be illustrated by team members having poor knowledge of upstream and downstream processes and how they fit into them. This in turn makes it hard to identify upstream/downstream areas that will be impacted by change, as well limits the ability to measure and justify change (specially improvements). This normally means Status-Quo is the rule, and change is only initiated after a business ‘catastrophe’ occurs.

b) Effective communication tools;
We have all experienced the occasion when we followed a known procedure, to later find out from a downstream process that we did not follow the ‘new’ process, or used an outdated document, thus resulting in repeating the work. (This specific scenario probably causes billions of pounds in wasted effort every year.)

In a manufacturing process, where a line stoppage can lead to enormous costs, it is imperative to communicate changes to ensure downstream stations are prepared and don’t receive a ‘line-stopping’ surprise. Business processes should be no different, however, seldom are business processes tied to exact execution times, and thus communication is not given high importance. In fact, it is typical to see communication happen reactively like this:

• Dept. B changed a form, and everyone in Dept. B. knows.
• Mr. X from Dept. A. uses the old form and submits to Dept. B.
• Mr. X is told the form is outdated and has to resubmit it to Dept. B.
• Mr. X now warns his Dept. A. colleagues to make sure they use the new form.

Effective communication tools and methods are critical to ensure everyone relevant to a change is instantly made aware of the change and the impact to their work.

In conclusion, when looking to improve your business processes ask yourself this: Do I have a documented process standard (typically process maps), and the right communication tools in place to ensure changes and their impact are immediately known across the organization?