29 Mayıs 2015 Cuma

Management Accounting : TOC & TA / Swain / 1999 / kitap özeti




Management Accounting : TOC & TA / M.Swain, J.Bell / 1999

 

  • Kısıtlar Yönetiminden azami fayda sağlamak için ürün stratejinizle uyumlu hale getirin.
  • Kısıtlar Yönetimi planlama DEĞİL, uygulama yöntemidir.
  • Fazla stoklar akışı yavaşlatır, maliyeti artırır, pazardan uzaklaştırır.
  • Sıfır stok DEĞİL, doğru yerde ve miktarda stok olması istenir.
  • Sistem kısıtları dahili veya harici olabilir:
    • Dahili : Proses (makine kapasitesi gibi), prosedür (asla fazla mesai yapma gibi)
    • Harici : Malzeme (eksik hammadde gibi), Pazar (satılandan fazla kapasite olması gibi)
  • 5 odaklanma adımı izlenir, bunlarla TA (Dönüşüm Muhasebesiyle) uyumludur.
  • Kısıtı iyileştirirken ürün stratejisiyle uyumlu kalınmalıdır, aksi takdirde önceden düşünülmemiş pazarlara veya ürünlere girilebilir.
  • TA mevcut muhasebe planının yerine DEĞİLDİR.
    • TA, çok kısa dönemli bir bakış açısıdır.
    • Raporlamayı DEĞİL, karar almayı kolaylaştırır.
  • T : Throughput : Dönüşüm : Satış fiyatından doğrudan hammadde ve komisyonları eksilterek bulunur.
  • T, geleneksel muhasebedeki Contribution Margin (Katkı) benzer. Ancak CM daha uzun vadeli bir bakıştır, T nin aksine direk işçiliği de hesaba dahil eder. T haftalardan söz ederken, CM aylardan söz eder.
  • OE : Operating Expenses : İşletme Giderleri dönemlik hesaplanır, doğrudan olmayan tüm harcamalar bu kalemdedir. Bu geleneksel muhasebeden önemli bir ayrılıktır. Geleneksel muhasebe bu harcamaları anahtarlarla dağıtır ve satılmadığı sürece gelir tablosuna getirmez, bilançoda biriktirir.
  • Geleneksel muhasebede maliyetler düşürülemese bile, stokların içine saklanabilir. Dolayısıyla örtülü olarak stok yapmak özendirilir.
  • CM yönteminde stok özendirilmez ancak bu sefer de üreticiler sadece en kârlı gördükleri ürünleri yapmaya çalışarak, pazardan uzaklaşabilirler. Ayrıca stratejik değeri olan uzun vadeli çabalardan soğutur.
  • Kısıtlar Yönetiminde hem gelir hem de kısıtlı kaynağın kullanımı birlikte yorumlanır, stokları düşürür, kaynak kullanımını ve üretimi artırır.
  • Dönüşüm Muhasebesi fiyatlamaya çok yardımcı olmaz, sadece kırılma noktasını gösterir, dağıtım anahtarları yoktur. Firmalar resmi düzende muhasebe sistemi kullanmalıdır, TA doğru ve hızlı karar için eklentidir.
  • Kültürel yansımaları olacaktır:
    • Beraberinde ölçme ve değerlendirme sistemi değiştirilmelidir
    • Artık yerel optimumlara bakılmamalıdır
    • Kısıta uygunluk sağlandığında kimse “boş duruyor” diye eleştirilmemelidir
    • Kaynaklar arası işbirliğini geliştirmek için konu çalışanlara tanıtılmalıdır
    • Kısıtın dışındaki kaynaklarda kapasite fazlası olması gerekir, hızlı ve katı kesintiler yapılmamalıdır
    • Kapasite fazlası için aksiyon düşürmek DEĞİL, bunu tüketecek kadar satabilmek olmalıdır
    • Paradigma değişimi sanıldığından daha zordur ve uzun sürer
  • Doğrusal Programlama bir çok bakımdan Dönüşüm Muhasebesine benzer, ancak;
    • TA uygulaması daha kolaydır
    • Doğrusal Programlama “yapılabilirliği” gösterse bile uygun bir çizelgeleme yapmaz
    • Doğrusal Programlamada kaynaklar arası bağımlılık ve prosesteki değişkenlik dikkate alınmaz

amazon review: Management Accounting : TOC & TA / Swain / 1999

The Theory of Constraints and Throughput Accounting
The Theory of Constraints and Throughput Accounting
by Monte Swain
Edition: Paperback


3.0 out of 5 stars Easy cross reference, too brief, May 28, 2015
A part of a series. There is a promoted web site but it is not effective anymore. There are interesting points:
Basic difference between TA and GAAP is time horizon. TA has very short term while GAAP has a very long term. It makes different cost items either fixed or variable.
Contrary to common belief TA is not to replace GAAT. You need GAAT for official reporting anyway.
TA is designed to make relevant decisions in the field, coupled with TOC and both of them are NOT for planning but for executing.
You need to keep TOC ligned with your strategy.
Linear Programming is interestingly similar to TA, gives feasible plans but there is no clue how to schedule it. Dependancy and variability in reosurces are not considered in it.

18 Mayıs 2015 Pazartesi

amazon review: Scrum / C.Sims / 2014


Scrum: a Breathtakingly Brief and Agile Introduction
Scrum: a Breathtakingly Brief and Agile Introduction
Chris Sims, H.L.Johnson

5.0 out of 5 stars to the point, eye opening!May 18, 2015
I have amazed that such a short book could let me understand what scrum is.
Actually it accomplished even more than this. Surprisingly it made me love it!
Thank you!

amazon highlights: Scrum / C.Sims / 2014

Scrum: a Breathtakingly Brief and Agile Introduction by Chris Sims, Hillary Louise Johnson
 Last annotated on May 18, 2015

What is Scrum?
Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products. it is not inherently technical and you can easily adapt the tools and practices described in this book to other industries.
A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in. One of the mantras of scrum is “inspect and adapt,” and scrum teams are characterized by an intense focus on continuous improvement—of their process, but also of the product.

Roles
Scrum recognizes only three distinct roles: product owner, scrum master, and team member
Product Owner
The product owner is responsible for maximizing the return the business gets on this investment (ROI). One way that the product owner maximizes ROI is by directing the team toward the most valuable work, and away from less valuable work. In scrum, no-one but the product owner is authorized to ask the team to do work or to change the order of backlog items. Another way that the product owner maximizes the value realized from the team’s efforts is to make sure the team fully understands the requirements. The product owner is responsible for recording the requirements, often in the form of user stories (eg, “As a <role>, I want <a feature>, so that I can <accomplish something>”) and adding them to the product backlog. Each of these users stories, when completed, will incrementally increase in the value of the product. 
As a <type of user>, I want to <do something>, so that <some value is created>.
The Product Owner Role in a Nutshell:
holds the vision for the product
represents the interests of the  business
represents the customers
owns the product backlog
orders (prioritizes) the items in the product backlog
creates acceptance criteria for the backlog items
is available to answer team members’ questions

Scrum Master
The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team’s deliverable is the product, a scrum master’s deliverable is a high-performing, self-organizing team. The scrum master helps the team learn and apply scrum and related agile practices to the team’s best advantage. The scrum master is constantly available to the team to help them remove any impediments or road-blocks that are keeping them from doing their work. The scrum master is not—we repeat, not—the team’s boss. This is a peer position on the team, set apart by knowledge and responsibilities not rank.
The scrum master role in a Nutshell:
scrum expert and advisor
coach
impediment bulldozer
facilitator

Team Member  
The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. A scrum team should posess all of the skills required to create a potentially shippable product. However, on a scrum team, each team member’s role is not to simply contribute in their special area. The role of each and every team member is to help the team deliver potentially shippable product in each sprint. What we are describing is a mindset change from “doing my job” to “doing the job.” It is also a change in focus from “what we are doing” (work) to what is getting done (results).

The Team Member Role in a Nutshell:
responsible for completing user stories to incrementally increase the value of the product
self-organizes to get all of the necessary work done
creates and owns the estimates
owns the “how to do the work” decisions
avoids siloed “not my job” thinking

7 +/- 2 So, how many team members should a scrum team have? The common rule of thumb is seven, plus or minus two. That is, from five to nine. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.

Scrum Artifacts These are the tools we scrum practitioners use to make our process visible.
The Product Backlog
The product backlog is the cumulative list of desired deliverables for the product. This includes features, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce. Generically, they are all referred to as “backlog items.” While backlog item is technically correct, many scrum teams prefer the term “user story,” as it reminds us that we build products to satisfy our users’ needs. The list of user stories is ordered such that the most important story, the one that the team should do next, is at the top of the list. Since stories near the top of the product backlog will be worked on soon, they should be small and well understood by the whole team. Stories further down in the list can be larger and less well understood, as it will be some time before the team works on them. Each item, or story, in the product backlog should include the following information:
Which users the story will benefit (who it is for)
A brief description of the desired functionality (what needs to be built)
The reason that this story is valuable (why we should do it)
An estimate as to how much work the story requires to implement
Acceptance criteria that will help us know when it has been implemented correctly

The Sprint Backlog
The sprint backlog is the team’s to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.

Burn Charts
A burn chart shows us the relationship between time and scope. Time is on the horizontal X-axis and scope is on the vertical Y-axis. A burn up chart shows us how much scope the team has got done over a period of time. Each time something new is completed the line on the chart moves up. A burn down chart shows us what is left to do. In general, we expect the work remaining to go down over time as the team gets things done. Sometimes the work remaining changes suddenly, when scope is added or removed. These events appear as vertical lines on the burn down chart.

Task Board
When the team’s tasks are visible to everyone from across the room, you never have to worry that some important piece of work will be forgotten. The simplest task board consists of three columns: to do, doing and done. Tasks move across the board, This visibility helps the team inspect their current situation and adapt as needed. The board also helps stakeholders see the progress that the team is making.

Definition of Done
In order to avoid confusion, good scrum teams create their own definition of the word “done” when it is applied to a user story. They decide together what things will be complete before the team declares a story to be done. This list of things that the team agrees to always do before declaring a story done becomes the teams “definition of done.” The team will likely print out their definition of done as a checklist, and post it next to their task board. When the team thinks a story is done, they all gather around and review each item, to confirm that it has been completed. Only then will the team declare the story as done.

The Sprint Cycle
The sprint  cycle consists of several meetings, often called ceremonies: sprint planning daily scrum story time sprint review retrospective
It’s about rhythm
a fixed period of time within which you bite off small bits of your project and finish them before returning to bite off a few more. The more frequently the team delivers a potentially shippable product increment, the greater freedom the business has in deciding when and what to ship.
Is the product potentially shippable? This is a decision for the team.
Does it make business sense to ship what we have at this time? This is a decision for the business.
The shorter the sprint cycle, the more frequently the team is delivering value to the business. The table that follows maps out the various meetings you would schedule during a one-week sprint. Formun Altı
  The meeting lengths shown are an appropriate starting point for a team doing one-week sprints.
Sprint Planning Meeting
Sprint planning marks the beginning of the sprint. Commonly, this meeting has two parts.
The goal of the first part is for the team to commit to a set of deliverables for the sprint. During the second part of the meeting, the team identifies the tasks that must be completed in order to deliver the agreed upon user stories. We recommend one to two hours of sprint planning per week of development.
Part One: “What will we do?”
The goal of part one of the sprint planning meeting is to emerge with a set of “committed” stories that the whole team believes they can deliver by the end of the sprint. The product owner leads this part of the meeting. One by one, in priority order, the product owner presents the stories he would like the team to complete during this sprint. As each story is presented, the team members discuss it with the product owner and review acceptance criteria to make sure they have a common understanding of what is expected. Then the team members decide if they can commit to delivering that story by the end of the sprint. This process repeats for each story, until the team feels that they can’t commit to any more work. Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.
Part 2: “How will we do it?”
stories are deliverables: things that stakeholders, users, and customers want. In order to deliver a story, team members will have to complete tasks. The product owner should be available during this half of the meeting to answer questions. The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks. The product owner agrees not to ask for additional stories during the sprint, unless the team specifically asks for more. The product owner also commits to being available to answer questions about the stories, negotiate their scope, and provide product guidance until the stories are acceptable and can be considered done.

Daily Scrum
Daily. at the start of their work day.
Brief. no more than 15 minutes.
Pointed. What tasks I’ve completed since the last daily scrum. What tasks I expect to complete by the next daily scrum. What obstacles are slowing me down.
The inspection happens in the meeting; the adaptation may happen after the meeting. This means that the team needn’t solve problems in the meeting: simply surfacing the issues and deciding which team members will address them is usually sufficient. 

Story Time
In this meeting you will be discussing and improving the stories in your product backlog, which contains all the stories for future sprints. Note that these are not the stories in the current sprint--those stories are now in the sprint backlog. We recommend one hour per week, every week, regardless of the length of your sprint. In this meeting, the team works with the product owner to: Define and Refine Acceptance Criteria. Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know when then the story is implemented as intended.

Story Sizing (Estimation)
Story Splitting
Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand, and easier for the team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list.
Sprint Review
This is the public end of the sprint; invite any and all stakeholders to this meeting.  If there are stories that the team committed to but did not complete, this is the time to share that information with the stakeholders.  Then comes the main event of this meeting: demonstrating the stories that did get done. This meeting is not a decision-making meeting. It’s not when we decide if the stories are done; that must happen before this meeting. It’s not when we make decisions or commitments about what the team will do during the next sprint; that happens in sprint planning. We recommend scheduling one-half to one hour for every week of development.

Retrospective
Scrum is designed to help teams continuously inspect and adapt, resulting in ever-improving performance and happiness. The retrospective, held at the very end of each and every sprint, is dedicated time for the team to focus on what was learned during the sprint, and how that learning can be applied to make some improvement We recommend one to two hours of retrospective time for each week of development. to identify no more than one or two strategic changes to make in the next sprint. It’s about process improvement.

Abnormal Sprint Termination (When Good Sprints Go Bad)
In scrum, the basic agreement between management and the team is that management won’t change up requirements during a sprint. If the product owner does decide to terminate the sprint early, the team will back out any changes that they have made during the sprint to avoid the problems that come from half-done work. Holding a retrospective is especially important after a sprint is abnormally terminated, as it helps the team learn from the experience.

Inspect & Adapt, Baby!
So, why do we do development work in these short cycles? To learn. Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback—from customers, from the team, from the market—and to learn from it. In scrum, we call this “inspect and adapt”; you might call it “continuous improvement”; either way, it’s a beautiful thing.

Agile Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan