Skip to main content

Goal: Making Money Now and In the Future

What is the Goal of a business?

This is the first question to answer in order to establish a process of on going improvement (POOGI). The goal must be clear, simple and measurable, and it must be understood by all players in the organization, who are involve somehow in improving the system. 
A general goal could be something like this "To make money by increasing net profit, while simultaneously increasing return on investment, and simultaneously increasing cash flow." as told by Alex to his team members in The Goal novel written by Dr. Eliyahu M. Goldratt. (in short making money now and in the future.)
Therefore, any action that moves the organization toward this goal is productive and any action that takes the organization away from it is non-productive. (this is not the same as efficiency, forget efficiency for now, this is about productivity and effectiveness, I deal with efficiency later).

Actually, such a goal can be applied to many for profit organizations. Let's take an Advertising Agency as an example. For such an agency Customer Satisfaction is critical but it may not be the goal. In fact, main goal (making money now and in the future) is dependent to customer satisfaction. Therefore any action that increases customer satisfaction will take the organization toward increasing net profit, return on investment and cash-flow.
Common Sense? 
Eli Goldratts has also proposed an alternative to traditional cost accounting to measure and monitor the goal and implemented changes in the "entire" organization and "the system"; called Throughput Accounting (TA). TA has been applied to many industries and hundreds of research papers and case studies have been written about it, but here it is in short:

TA focuses on three main measurements and their relationship together: throughput, Investment and Operational expenses.
  • Throughput is the rate at which the system generates money through sales. Throughput is through sales and not production, if you produce and not sell, it is not throughput.
  • Inventory is all the MONEY that the system has invested in purchasing things which it intends to sell. This could be Raw materials, machinery, premises, finished goods, work in progress (WIP), Ideas, requirements and etc. Therefore, a high level of inventory in the system causes a high level of liability as inventory consists of items such as unfinished work, unrealised ideas, unfinished products and undelivered projects.
  • Operational expenses is all the money the system spends in order to turn inventory into throughput. Such as labor cost.
Measurements used by TA ensures all improvement, changes and actions focus on the ultimate goal of the whole system and organization as its entirety. Based on TA, the longer it takes to produce a product or completing a project the higher the inventory; high inventory results in low Return of investment and cash-flow which it is against the Goal. Therefore, TA promotes faster production and faster project delivery.

It is important to know that the goal of TA is not to treat each measurement in isolation, the goal is to reduce operational expenses and reduce inventory while simultaneously increasing throughput for the entire organization or system.

Based on the above, you may conclude that to stay focus on the goal and therefore simultaneously improve three TA measurements, we should have a balance system, meaning we have to match the capacity of each and every resource to market demand.
However, Goldratt demonstrates that there is a mathematical proof which could clearly show when capacity is trimmed exactly to market demand, no more and no less, throughput goes down, while inventory goes through the roof and therefor your organization goes away from its main goal (i.e making money now and in the future).

The combination of two phenomenons cause a balance system to fail and a system or organization with excess capacity to succeed: Dependent Events and Statistical Fluctuation.
  • Dependent Events: Series of events that must take place before another can begin, the subsequent event depends upon the ones prior to it.
  • Statistical Fluctuation: Not all factors in the system can be predicted precisely, and therefore there is a different statistics for each event to occur at any single time. 

Events depend to each other and rarely they occur one after each other one at the exact time. Many factors may impact the duration of one event. Things happen at various speed at different times, the accumulation of such fluctuation impacts the whole system. So, when you combine dependent events and statistical fluctuation phenomenons, you understand that balancing a system or organization will not work by matching the demand to exact capacity. 
As, statistical fluctuation will strike and system will not have excess capacity to recover delays and accumulated fluctuation will increase work in progress, as a result operational cost goes up ,and return on investment goes down; and organization goes away form the goal.

Summary:
  • To establish Process of Continues Improvement, you must set a clear and measurable Goal for the entire system
  • The goal must cover the system as it's entirety, not one department, but the whole organisation.
  • The goal must be measurable based on throughput accounting principles.
  • Throughput accounting focuses on three measurements and their relation : Throughput, Inventory and Operational Expenses.
  • The goal of throughput accounting is NOT to focus on each measurement in isolation, they are deeply interrelated.
  • Throughput Accounting promotes fast production and fast project delivery.
  • Matching demand exactly to resource capacity to have a balance system will imbalance the entire organisation, because of the combination of the two phenomenons: Dependents Events, Statistical fluctuation.
  • Excess Capacity on resource level is Good and Necessary.
Post a Comment

Popular posts from this blog

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to KanbanFrom High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important. 
Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate. 
Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while, they deploy their …

New Organisational Model For Project Based Companies

Elliot Goldratt suggested a Strategy Tree for project based companies. While that may work for some companies, it will not work for knowledge based workers or Software Development Companies, or Digital Agencies. On the other hand traditional resource planning and resource allocation is also not effective despite all the effort one put into it to make it less of a command and control model - Here I assume we know who are knowledge workers and how their productivity works, Peter Drucker has a fantastic article about Knowledge Workers that I highly recommend you to read, if you have not read it yet: http://www.forschungsnetzwerk.at/downloadpub/knowledge_workers_the_biggest_challenge.pdf
Also, it has been proven that stable teams work better together on long term projects in software development. However, almost majority of software development companies or digital agencies break teams and reassemble them based on new projects or clients. This creates unnecessary complication and waste w…

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…