Saturday, April 20, 2013

Планиране на проект с помощта на Закона на Литъл

Въведение


Законът на Литъл работи със средни стойности. Той ни помага да изчислим средното време което една заявка прекарва във системата. Когато изпълняваме проект ние разбиваме на части продукта, който трябва да се достави като резултат от проекта. Ние се интересуваме колко време ще отнеме на системата за да изработи всички части. Точно това е което прави Формулата на Андерсън – тя ни дава зависимостта между средното оперативно време за дадена част и времето за което целият проект ще може да се достави.


Закон на Литъл


Нека си припомним, че за производствени системи Законът на Литъл се записва по малко по-различен начин, а именно:

където WIP (количество незавършена продукция) e складовата наличност между началната и крайната точка на производственият процес; TH (дебит) e средният брой произведени продукти; CT (оперативно време) е средното време между постъпването на една заявка в производството до складирането и като готов продукт или с други думи времето което заявката прекарва като WIP. Този закон е валиден за всяка една система още повече, че може да се приложи и за подсистеми или система в системата. Например в банка, опашката пред касиерите може да е една система, а всеки един от касиерите друга система и Законът на Литъл може да се приложи за всяка една от тях както и към всички заедно. Нарочно използвам TH, WIP и CT за по-лесна ориентация при четене на документи на английски.



Формула на Андерсън


Нека разгледаме следният случай от практиката - планиране на проект. На Фиг.1 имаме две нива на производствената система и съответно две гледни точки (перспективи):

  • • Ниво Проект - проект или работа значима за клиента
  • • Ниво Разработка - компонент или работа значима за екипа. Един пример са сторитата използвани при разработката на софтуер
Проекта ще се достави за времето T. Ние разбиваме доставката на N броя неща за правене или единици работа. Всички те влизат едновременно във Опашка Разработка. Размера на отделните единици работа е без значение. Когато разбиваме проекта ние не вземаме предвид от колко стъпки се се състои процеса на сървъра S2. Важно е да се отбележи, че имаме две опашки - Проект и Разработка. Опашката Проект е с размер N и Опашката Разработка е с размер [0,N]. Сървър S1 може да има оперативно време по-голямо от 0 ако това което прави е да определи коя ще е следващата работа изтеглена от опашката Проект в опашката Разработка.





Фиг.1


Ние можем да получим времето на доставка използвайки формулата:




или ако искаме да разберем колко човека ни трябват за да доставим за определено време:




 Където:

  T              - времето за което проекта ще бъде завършен
  N              - броят единици работа, които трябва да се свършат в интервала [0,T]
      – средното оперативното време на ниво проект или както го вижда клиента
 – средното количеството незавършена работа на ниво проект
 – средното количеството незавършена работа на ниво екип
     – средното оперативното време на ниво екип
     – средният дебит на ниво проект
    – средният дебит на ниво екип


Разбира се THе средната стойност на случайна величина с даден вид разпределение. Ако изходящият поток може да се моделира като Поасонов процес с интензитет THтогава нужното време за N-тата единица работа да излезе от системата се моделира с Гама разпределение Γ(α,β) със a=N и b=1/THt.

Доказателство на Формулата на Андерсън



Прилагаме Законът на Литъл за клиентското ниво:
Прилагаме Законът на Литъл и за производственото ниво:


На Фиг. 1 двете системи – клиентската и производствената са свързани като изхода на производствената се влива в изхода на клиентската. Следователно дебита на клиентската система е равен на дебита на производствената или 
. И в двата случая при пресмятания с помощта на Законът на Литъл трябва да използваме една и съща мерна единица за времето - минути, часове, дни и т.н. Не може да се пресмята когато дебита да е измерен в часове, а пък оперативното време да е в дни. Също така трябва да имаме една мерна единица за работата.









By noting that

Следва:


Също както и:
or



Примери


Оригиналният пример на Дейвид Андерсън


Имаме да доставим голям проект от 2200 единици работа. Клиента иска доставката на целият проект след 10 месеца.Трябва да отговорим на въпросите: Колко ще ни струва доставката на проекта? От колко човека ще се нуждаем?
Тоест имаме N = 2200 единици работа, T=10 месеца = 40 седмици. Ние имаме исторически данни за организацията разработчик които показват, че средното оперативно време за единица работа е 0,4 седмици. Използвайки Формулата на Андерсън (2) имаме:
Организацията разработчик следва правилото за само една единица работа на човек в даден момент следователно ще ни трябват 22 души. Тук приемаме, че опашката Разработка има дължина 0 единици работа. Ако тя има дължина от 2 единици работа то ние ще се нуждаем от 20 човека.
Този резултат трябва да се използва за средната част на Z-кривата, но това е друга тема.


Пример за определяне на датата на доставка


Нека имаме да доставим голям проект от 2200 единици работа. Клиента иска да знае кога ще можем да го доставим. Нямаме опции за добавяне на допълнителен персонал към организацията, която в момента е 22 човека и следователно средното количеството незавършена работа ще ни е 22 единици. Ние имаме исторически данни за организацията разработчик които показват, че средното оперативно време за единица работа е 0,4 седмици. Използвайки Формулата на Андерсън (1) имаме:

Този резултат трябва да се използва за средната част на Z-кривата, но това е друга тема.


Източници:

Little, J. D. C., S. C. Graves. 2008. Little’s Law. D. Chhajed, T. J. Lowe,eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC,New York.

J. D. C. Little. Little's law as viewed on its 50th anniversary. Oper. Res. 59 (2011) 536{539.

Thursday, April 11, 2013

Project planning using Little’s law

Introduction


Little's Law deals with averages. It can help us calculate the average waiting time of an item in the system. In project development we break the project delivery into work items. We are interested in how much time it will take for all the items to be processed by the system. And that is what Anderson's formula does - it gives us the relationship between the average lead time for an item and the finite time period over which the project will be delivered.

Little’s Law


Let’s recall what the Little’s Law for production systems is:
Where throughput (TH) is the average output of a production process (machine, workstation, line, plant) per unit time,  work in process (WIP) is the inventory between the start and end points of a product routing, and cycle time (CT) is the average time from release of a job at the beginning of the routing until it reaches an inventory point at the end of the routing (that is, the time the job spends as WIP). Handily this result applies to any system, and particularly, it applies to systems within systems. So in a bank, the queue might be one subsystem, and each of the tellers another subsystem, and Little's result could be applied to each one, as well as the whole thing.


Anderson’s Formula


Let’s consider project planning. On Fig.1 we have two levels of the system and hence two perspectives on it:
  • Client layer – project or set of customer defined requirements meaningful to the customer.
  • Service level – components or work items suitable for the development organization. User stories are just an example of a suitable work item type
The project will be delivered in the time T. We break down the project into N work items. All the items enter Project Queue. The size of the individual work items doesn't matter. When breaking a project down we do not consider how many steps the workflow of server S2 consists of. Important thing is that we have two queues - Project and Dev. Project queue has the size of N and Dev queue could be of any size in [0,N]. Server S1 could have service time of more than 0 if for instance what it does is to decide which would be the next item to leave Project queue and enter Dev queue.




Fig. 1


We can calculate the lead time for the project using the formula:




We can calculate the developers we will need to deliver for a particular lead time using the formula:




 Where:

  T              = time period over which the project will be delivered (lead time)
  N              = the number of items to be delivered or the total arrivals in [0,T]
      = average lead time at the project level or what the client can see
 = average work in process at the project level
 = average work in process at the development organization level
      = average lead time (cycle time) at the development organization level
     = average throughput at the project level
    = average throughput at the development organization level



Of course THis the average of a random variable modeled by a distribution of some type. If the departure is a Poisson process with intensity THthen the required time for N-th work item to exit the system (be delivered) is modeled by a Gamma distribution Gamma(a,b) with a=N and b=1/THt.


Proof of Anderson’s Formula



We apply Little’s Law at the client level:
Then we apply Little’s Law at the development organization level:


Consider Fig.1 where the project is presented as a queuing system consisting of two queuing systems in tandem. Client and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or 
For both systems we have to work with the same time interval for the throughput time and throughput rate i.e. minutes, hours, days, weeks, etc. Also we have to have the same work item type – it is not possible average throughput at the project level to be measured in sites, and average throughput at the development organization level to be measured in web pages.









By noting that

It follows that


As well as that
or



Examples


Original example from David Anderson


We have a major project with 2200 user stories to be delivered. The business needs the project delivered in 10 months. The questions to answer are: How much money do we need? How many people do we need?
So we have N = 2200 user stories, T=10 months = 40 weeks. We also have historical data that average lead time for the development organization is 0,4 weeks. Using the Anderson’s formula (2) we have:
Development organization has the policy of 1 work item per person hence we will require 22 persons. That assumes the dev queue has finite size of 0 work items. If the dev queue has finite size of 2 user stories we will need 20 persons.
The result should be used for the second leg of the Z-curve, but that is another topic.


Calculating delivery date


Let’s have a similar project with major project with 2200 user stories to be delivered. The business wants to know when we will be able to deliver. There are no options for adding more developers to the development organization so we know the average work in process which is 22 user stories.  We also have historical data that average lead time for the development organization is 0.4 weeks per user story. Using the Anderson’s formula (1) we have:

The result should be used for the second leg of the Z-curve, but that is another topic.


References:

Little, J. D. C., S. C. Graves. 2008. Little’s Law. D. Chhajed, T. J. Lowe,eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC,New York.

J. D. C. Little. Little's law as viewed on its 50th anniversary. Oper. Res. 59 (2011) 536{539.

Thursday, March 28, 2013

Какво е проект?

Вчера вечерта изнесох лекция на тема "Въведение в Канбан" в betahaus. Нарочно наблегнах на системното мислене и как Канбан ни позволява да стабилизираме всяка една система ползваща интелектуален труд. Един от присъстващите попита дали мога да опиша система, която работи само по проекти?
Моят отговор беше, че независимо дали една организация работи по проекти или не ние пак трябва да я разглеждаме на първо място като система.
Днес ми хрумна един пример, който мисля ще илюстрира тезата ми - пътуване с кола от точка А до точка Б.
Аз всеки ден пътувам с кола от къщи до офиса. Отнеме ми  средно около 10 мин и го смятам за рутинно упражнение. Факта, че го смятам за рутинно показва, че вариацията е много малка и точно затова аз мога да предвидя времето за пътуване (оперативното време) с голяма сигурност.
Ако обаче реша да отида до Габрово това ще е съвсем друга история. Първо - никога не съм ходил до Габрово и съответно не зная кой път да хвана. Второ - не познавам условията по пътя -  брой дупки, брой тирове и други подобни. Трето  - трябва да осигуря финансиране за да мога да си платя горивото необходимо за пътуването. Видно е, че вариацията е много голяма и ако трябва да предвидя времето необходимо за пътуването аз ще трябва да поработя върху план.

Пътуването до Габрово е проект. Пътуването до офиса е рутина. Но и двете пътувания ще бъдат изпълненеи от системата състояща се от мен като шофьор, колата и пътната мрежа.

Monday, March 04, 2013

Goethe’s Other Coptic Song – Ein Andres



Ein Andres (Kophtisches Lied II)



Geh! Gehorche meinen Winken,

Nutze deine jungen Tage,

Lerne zeitig klüger sein!

Auf des Glückes großer Waage

Steht die Zunge selten ein.

Du mußt steigen oder sinken,

Du mußt herrschen und gewinnen

Oder dienen und verlieren,

Leiden oder triumphieren,

Amboß oder Hammer sein.




Йохан Волфганг Гьоте , "Кофтска песен "
Превод от немски: Димитър Стоевски




Чуй и следвай моите думи

    не пилей напразно дните,

    постарай се да си умен —

    рядко случва се везните

    на съдбата да са спрели.

    Ще се дигаш или падаш,

    ще владееш и печелиш,

    ще робуваш и ще губиш,

    ще ликуваш или страдаш

    длъжен си да бъдеш тук

    наковалня или чук!





Translated by James Clarence Magnan



Go ! — but heed and understand

This my last and best command :

Turn thine Youth to such advantage

As that no reverse shall daunt Age.

Learn the serpent’s wisdom early ;

And contemn what Time destroys ;

Also, wouldst thou creep or climb,

Chuse thy role, and chuse in time,

Since the scales of Fortune rarely

Shew a liberal equipoise.

Thou must either soar or stoop,

Fall or triumph, stand or droop ;

Thou must either serve or govern,

Must be slave, or must be sovereign ;

Must, in fine, be block or wedge,

Must be anvil or be sledge.



Translated by Edgar Alfred Bowring



Go! obedient to my call,

Turn to profit thy young days,

Wiser make betimes thy breast

In Fate’s balance as it sways,

Seldom is the cock at rest;

Thou must either mount, or fall,

Thou must either rule and win,

Or submissively give in,

Triumph, or else yield to clamour:

Be the anvil or the hammer.

Translated by William Grasett Thomas



Go ! thy master’s beck obey,
Profit of thy early days,
“Wisdom learn without delay :
On the scales of Fortune stays
Seldom e’er the tongue at rest ;
Rise thou must, or be depressed,
Rule and gain must be for thee,
Or must learn to serve and lose,
Triumph must or suffering choose,
Hammer must or anvil be.




Thursday, February 28, 2013

Д-р Деминг извършва "Експеримента с Червените топчета"


Много интересно видео показващо как д-р Деминг извършва "Експеримента с Червените топчета".



Wednesday, February 27, 2013

How can we move variability out of the system?


How can we move variability out of the system? By outsourcing it.

"...Needless to say, the loss of industrial jobs is a disaster for industrial workers, and for politicians whose efforts depend on large pools of organized labor (more on that later). But unless one is an industrial
worker, a trade union, or a left-wing democratic politician this is great news. Why? Because it means that the underlying economy loses most of its cyclicality. Let us explain:
• The industrial part of the production process is by far the most cyclical of the three step (design, produce, sell) process described in the first chapter.
• So as companies outsource the ‘production’ part, they effectively outsource the volatile part of the business process to someone else.
• This means that, when underlying economic activity is weaker then had been forecast, Western companies do not end up with the excess inventories, excess labor etc. It is the suppliers that have
to deal with any excesses left over by the unforeseen economic soft spot.

To illustrate this, imagine the following situation. Due to an unexpected event (9/11? Tech bust? Very cold weather?) furniture sales in North America are all of a sudden much weaker than had been anticipated
initially by IKEA. So what does IKEA do? It picks up the phone and calls its supplier in Indonesia (or Poland, Mexico etc.) and says:
Ikea: “Sorry. I know that, this time last year, we ordered 50,000 cupboards from you. But this month, we will only need 5,000.”
Supplier: “But I have already bought the wood for 50,000 cupboards?”
Ikea: “Really? Then I guess you can give me a special deal on the 5,000 cupboards that I do need. After all, you will want to get rid of your wood inventory.”
Supplier: “But how am I supposed to make my employee payrolls?”
Ikea: “Sorry my friend. There are two kinds of problem in the capitalist world in which we live: mine, and not mine. Your inventory and payroll issues are the second kind of problem.”

Because of the slowdown in the demand for furniture, the supplier in Mexico (or elsewhere) is then forced to lay off people. Meanwhile, the designers at IKEA are hard at work on finding new designs that will draw
people back into the stores, as are the IKEA marketing teams. In neither of the latter two activities do we witness many lay-offs. IKEA’s people in Sweden and the United States remain duly employed and the shock is absorbed by the Mexican economy."

From one very interesting quite old but still very relevant book Our Brave New World

Written by Anatole Kaletsky, Charles Gave, Louis-Vincent Gave
Edition: GaveKal Research

Thursday, February 21, 2013

Resilient Architecture

Resilient Architecture principle: Early detection - Fast recovery.

Hindsight doesn't lead to foresight!

Законът на Литъл е всъщност само частен случай...

Законът на Литъл L = λW всъщност е частен случай на по-общата теорема (Закон на Брумел) H = λG където за всеки елемент влизащ в системата се дефинира тегловна функция fi(t). Подробно описание има в използваната литература.

H = λG ни позволява да сложим различни тегловни функции, например разход или печалба на времето, което всеки елемент i прекарва в системата. Законът на Литъл е частен случай където fi(t)=1 за t ∈  [ti,ti+li] и li=Wi

Пример:

Магазин сайт има средно 1000 клиента/ден. Всеки клиент харчи средно по 5 лв. Искаме да знаем колко е средният приход на магазина на ден. Използвайки закона на Брумел:

H (среден приход на ден) = λ (среден брой клиенти на ден) G (среден харч от клиент)=1000 клиента/ден * 5 лв = 5000лв/ден



Използвана литература:

Wednesday, February 13, 2013

Кога е приложим Законът на Литъл?

Нека си припомним, че Законът на Литъл гласи, че "усредненият брой на елементите в системата (L) е равен на усредненото темпо, с което тези елементи постъпват (λ) в системата, умножена по усредненото време което даден елемент прекарва (W) в системата".

 L = λW (1)

Законът на Литъл е валиден в случаите когато имаме:

  • стабилна система - стационарен стохастичен процес на постъпване на елементите в системата и и стационарен процес на обслужване на елементите. 
  • нестабилна система - нестационарен стохастичен процес на постъпване на елементите в системата и и стационарен процес на обслужване на елементите, но пък 1) времевият интервал в който наблюдаваме системата е ограничен 2) в началото и краят на наблюдението системата е празна; 3)всички постъпили елементи ще бъдат обслужени и ще напуснат системата т.е. няма "загубени"

И в двата случая при пресмятания с помощта на Законът на Литъл трябва да използваме една и съща мерна единица за времето - минути, часове, дни и т.н. Не може да се пресмята когато дебита да е измерен в часове, а пък оперативното време да е в дни.

При нестабилна система ние не можем да използваме Законът на Литъл докато системата не се изпразни. Това не е недостатък - просто показва, че ние измерваме какво се е случило, а не предвиждаме какво ще се случи. Още нещо за отбелязване е, че ако интервалът на наблюдение е да кажем 1 ден то всеки един отделен ден резултата от изчислението ще е различен, но Законът на Литъл ще е валиден.

Какво се разбира под "усреднен"? Това не са очаквани стойности защото ние не работим с разпределяния на случайни величини. Когато говорим за темпото на постъпване и времето на обслужване се разбира усреднени стойности на извадката. Когато се говори за опашката се има предвид усредненият брой за фискиран времеви интервал. 

За производствени системи Законът на Литъл се записва по малко по-различен начин, а именно:

TH=WIP/CT (2)

където WIP (количество незавършена работа) e средният брой изпълнявани заявки между началната и крайната точка на прозводственият процес; TH (дебит) e средният брой изпълнение заявки; CT (оперативно време) е средното време между постъпването на една заявка в производството до завършането и или с други думи времето което заявката прекарва като WIP.

Такава система не е стабилна и затова за да приложим Законът на Литъл ще трябва да имаме система закоято са изпълнени условията за нестабилна система, а именно:
  • Времевият интервал в който наблюдаваме системата е ограничен.
  • Използваме една и съща мерна единица за времето за всички параметри.
  • Ако системата се изпразва то тя трябва да е празна в краят на времевият интервал.
  • Ако системата никога не се изпразва то: 
    • количеството незавършена работа (WIP) в началото на измерването трябва да е приблизително равно на количеството в края на измерването така, че няма значително увеличаване или намаляване. Това покрива изискването системата да е изпразнена в края на времевият интервал.
    • Средната възраст на количеството незавършена работа (WIP) не трябва нито да се увеличава нито да намалява по време на измерването. 

След като изложихме свойствата които дадена система трябва да има за да можем да приложим Законът на Литъл нека изложим нещо също толкова важно  - системните характеристики на които не трябва да обръщаме внимание за да го прилагаме:
  • Големината на елементите влизащи в системата
  • Разпределението на стохастичен процес на постъпване на елементите в системата и и стационарен процес на обслужване на елементите
  • Колко човека работят върху определена заявка
  • Реда на изпълнение на заявките
  • И всичко друго за което се сетим!



Използвана литература:

Monday, February 11, 2013

Примери за използването на Законът на Литъл

Нека отново напишем Законът на Литъл:


TH=WIP/CT

където WIP (количество незавършена продукция) e складовата наличност между началната и крайната точка на прозводственият процес; TH (дебит) e средният брой произведени продукти; CT (оперативно време) е средното време между постъпването на една заявка в производството до складирането и като готов продукт или с други думи времето което заявката прекарва като WIP.

Нарочно използвам TH, WIP и CT за по-лесна ориентация при четене на документи на английски.

Няколко примера:

1) Продавач във магазин има средно 4 клиента на опашка на касата. Нов клиент пристига средно на 2 минути. Колко време средно ще чака един клиент за да бъде обслужен?

TH(дебит)=0,5клиента/мин
WIP (количество незавършена работа)=4 клиента
CT(оперативно време)=WIP/TH=4/0,5=8 минути

2) Ресторант има места за 60 човека. Един човек прекарва средно по 2 часа в ресторанта. Колко човека влизат в ресторанта средно на час?


WIP (количество незавършена работа)=60 клиента
CT(оперативно време)=2 часа
TH(дебит)=WIP/CT=60/2=30 човека/час


3) Застрахователен брокер получава средно по 160 запитвания на ден за продуктите които предлага. Обработката на една запитване отнема средно 30 минути. Ръководството иска да е сигурно, че всяко едно запитване ще бъде обработено в деня в който е получено. Приема се че всяко запитване се обработва само от един служител. Колко служителя ще са необходими за обработка на запитванията?

CT(оперативно време)=0,5 запитвания/час
TH(дебит)=160 запитвания/ден=20 запитвания/час
WIP (количество незавършена работа)=TH*CT=20*0,5=10 заявки*1 служител=10 служителя

За правилното използване на Закона на Литъл трябва да се уверим, че се използва същата мерна единица за време (час, минути, ден) за Оперативното време и за Дебита.

4) Ресторант за сандвичи използва 3500кг месо на седмица. Управителя иска да е сигурен, че когато се използва месото е на не повече от 2 дена. Колко килограма месо трябва да се поддържат в хладилника?

CT(оперативно време)=2 дни
TH(дебит)=3500кг/седмица=500кг/ден
WIP (количество незавършена работа)=TH*CT=500*2=1000кг

Saturday, February 09, 2013

Закон на Литъл

Преди малко повече от 50 години беше доказана теорема, която въпреки че не е със сложна природа, има силно въздействие върху множество браншове. Законът на Литъл остави своя отпечатък върху лечебни заведения, банки, магазини и производствени предприятия всяко едно от които може да се разгледа като Система за Масово Обслужване(СМО).

През 1961 г.  Джон Литъл (в момента M.I.T. професор) доказа, че за СМО "усредненият брой на елементите в системата (L) е равен на усредненото темпо, с което тези елементи постъпват (λ) в системата, умножена по усредненото време което даден елемент прекарва (W) в системата".

 L = λW (1)


Тук е оригиналната статия http://or.journal.informs.org/content/9/3/383.abstract

Тук http://www.informs.org/content/download/255808/2414681/file/little_paper.pdf е прегледа от автора по повод 50 годишнината на теоремата.

След като го прочетете за първи път, законът може да предизвика известно объркване, но със реалистични примери теорията става ясна. "Системата" може да бъде всяко едно обслужващо клиенти предприятие например магазин, банка, екип за разработка на софтуер или накратко всяка една СМО. В Рексинтегра ние ползваме този закон за управление на проектите за разработка на софтуер.

Пример, илюстриращ СМО е една бензиностанция с няколко колонки, които представляват обслужващи устройства. Автомобилите, които постъпват за обслужване – това са клиентите (или заявките за обслужване). Темпото на пристигане на клиентите  (λ) има случаен характер. Времето за зареждане на всеки един клиент (W) също е със случаен характер.

Законът на Литъл се отнася за СМО. СМО се състои от отделни обекти които ще наричаме заявки които постъпват в системата с определено темпо. Вътре в системата заявките могат да образуват една или повече опашки, изпълняват се и накрая напускат системата.
Фиг. 1 показва това схематично:


В повечето случаи изпълнението на заявките се явява стеснението заради което се образуват опашките от чакащи заявки, и затова обикновенно имаме време за изпълнение по-голямо от нула. Ако имаме време за изпълнение приемаме, че имаме и време за изчакване. Понякога се прави разлика между брой заявки в опашката и общ брой изчакващи в опашки и изпълнявани заявки, като второто се нарича брой заявки в системата.

За производствени системи Законът на Литъл се записва по малко по-различен начин, а именно:

TH=WIP/CT (2)

където WIP (количество незавършена продукция) e складовата наличност между началната и крайната точка на прозводственият процес; TH (дебит) e средният брой произведени продукти; CT (оперативно време) е средното време между постъпването на една заявка в производството до складирането и като готов продукт или с други думи времето което заявката прекарва като WIP.

Лесно се вижда, че (2) е еквивалентно на (1) като TH=λ, WIP=L и CT=W. Обаче има една по-голяма разлика и тя е, че законът е зададен със средното темпо на напускане вместо със средното време за постъпване в системата.
Това отразява една производствена система където "напускането" на готовите продукти е смисълът за съществуването на системата. Както се вижда за да увеличим дебита трябва или да увеличим количеството незавършена продукция или да намалим оперативното време или и двете заедно.

Нека отделим време за да осмислим Законът на Литъл. Той има ли отражение върху начина на работа на вашата организация? Ако да - как? Ако не - защо?

Wednesday, January 16, 2013

Българската култура: Пример 1

Статия във в-к Сега брой 4590 (13) 16.01.2013г


Групата трябва да се пази


"Времето е смутно, тече възродителен процес. Няколко турчета са подчинени на Горанов. Той не ги закача. От градския комитет на партията му се обаждат ту да ги уволнява, ту да ги назначава. Горанов ги пази, обръща се към тях с родните имена....На Варненския митрополит Кирил, сложих си ръка на сърцето и му казах: не съм вярващ. Но ние сме християни хора. В църквите не виждам лошо. Църквата на нищо лошо не ни учи, напротив - обединява хората, да стават по-добри....Писахме писма до партии, банки, институции. Но трябва да ти призная, и заради малко връзки стана."

Законите не важат за всички


"Село Дръндар, родното на Ахмед Доган, също е в община Суворово. Кметските наместници редовно се събират в административния център, правят оперативки. Наместник в Дръндар е Зюмбюл Али, сестра на Касим Дал....Веднъж Зюмбюл и Горан се разприказват, от дума на дума той праща поздрави на стария си приятел бай Ахмед. "Знаеш ли го", пита Горан. "Е как, той ми е комшия", възкликва Зюмбюл. Ахмед казва добри думи за Горан....Преди това Зюмбюл съдейства и за ремонт на пътя между Баново и съседното село Калиманци. Отива суворовска делегация в София при Доган, него го няма. Касим Дал, в отлични отношения със Сокола тогава, разписва за ремонта. Скоро ужасното шосе е чисто ново....Бай Горан не страда от лицемерие: "Връзките помагат". Надълго и широко разказва как са помагали и през комунизма."

Вижда се високи PDI, UAI, нисък LTO (Hofstede);
Вижда се Ascription status, Specific relationships, Defuse relationships ( Trompenaars);





Sunday, January 13, 2013

IDV and how it affects outsourcing



Universalism vs. Particularism (Trompenaars)

Universalism is the belief in:
  • rules or laws that can be applied to everyone;
  • agreements and contracts are used as the basis for doing business;
  • rules are used to determine what is right;
  • contracts should not be altered;
  • ideas and practices can be applied everywhere without modification.
Particularism is the belief in:
  • placing emphasis on friendships and looking at the situation to determine what is right or ethically
  • acceptable
  • deals are made based upon friendships;
  • agreements are changeable;
  • different people hold different views about reality;
  • circumstances dictate how ideas and practices should be applied.

Individualism vs. Collectivism (Hofstede)

Individualism is the belief in: 


  • Everyone is supposed to take care of him- or
  • herself and his or her immediate family only
  • "I" – consciousness 
  • Right of privacy 
  • Speaking one's mind is healthy 
  • Others classified as individuals 
  • Personal opinion expected: one person one vote 
  • Transgression of norms leads to guilt feelings 
  • Languages in which the word "I" is indispensable 
  • Purpose of education is learning how to learn 
  • Task prevails over relationship 


Collectivism is the belief in:


  • People are born into extended families or clans which protect them in exchange for loyalty
  • "We" –consciousness
  • Stress on belonging
  • Harmony should always be maintained
  • Others classified as in-group or out-group
  • Opinions and votes predetermined by in-group
  • Transgression of norms leads to shame feelings
  • Languages in which the word "I" is avoided
  • Purpose of education is learning how to do
  • Relationship prevails over task




"The distinction between in-group and out-groups that is so essential in collectivist culture pattern has far-reaching consequences for business relationships, beyond those between employers and employees. In individualist societies the norm is universalist, treating everybody alike. Preferential treatment of one customer over others is considered bad business practice and unethical. In collectivist societies the norm is particularist. As the distinction between "our group" and "other groups" is at the very root of people's consciousness, treating one's friends better than others is natural  and ethical and sound business practice." p. 238, Culture's Consequences, G. Hofstede

"A consequence of particularist thinking it that in a collectivist society a relationship of trust should be established between two parties before they can do any business. Through this relationship, both parties adopt the other into their in-groups, and from that moment onward both are entitled to preferential treatment. This process of adoption takes time - depending on the situation, from several hours to several years.  A relationship is established with a person rather than with a company. To the collectivist mind, only natural persons are worthy of trust, and via these persons their friends and colleagues, but not impersonal legal entities like companies. So in the collectivist society the personal relationship prevails over the task and over the company and should be established first; in the individualist society, in contrast, the task and the company are supposed to prevail over any personal relationships. Naive Western businesspersons who try to force quick business in collectivist culture condemn themselves to negative discrimination as out-group members." p. 239, Culture's Consequences, G. Hofstede

According to http://geert-hofstede.com/bulgaria.html Bulgaria with a score of 30 is considered a collectivist society. 

From Asia: India scores 48, but at a score of 20 China is a highly collectivist culture!

With a score of 46, also in this dimension Argentina sits in the middle rankings. As a consequence of the aforementioned migration waves and the early emergence of wide middle classes, Argentina is, by far, the most individualistic of all Latin countries.

For a comparison The United States, with a score of 91 on this dimension, is a highly individualistic culture. 


Wednesday, December 26, 2012

Dave Snowden's thought #2


"If the system is chaotic/random then agent behaviour is
deterministic, which means I can use statistical instruments. If it’s constrained,
then the constraint structure allows predictability/repeatability. Strong
constraints produce linear causality; weaker constraints provide repeatability
that may be non-linear. However the moment you get the phase shift into a
co-evolutionary relationship between agents and system then there is no repeatability
except by accident. In that context there is no meaningful causality, and
any causality is only retrospectively coherent."

Dave Snowden's thought #1

It is good to have Dave Snowden's thoughts on paper, because most of them I have only on video.
Here is the first one:

"We manage the emergence of beneficial coherence, within attractors, within boundaries.  The only things we can manage are the probes, the boundaries and amplification/dampening of emergent patterns. " from The Children's Party Story