www.FORUM.MBQ.ru
-
Конверсионные продукты (мечи на орала)
.  1, 2, 3, 4  .
 
           www.forum.mbq.ru -> Голдрат и TOC
::  
Yosha



: 16.04.2007
: 242
: Москва

: 10, 2007 3:16 pm     : Re: Конверсионные продукты (мечи на орала)

Сахават ():
Yosha ():
Сахават ():

- надо встроить имитатор

Блин. как все запущенно! Получается что черный ящик дает мне ответ, а я даже не могу проверить что было бы, если я использовал другой алгоритм?

Вы грили что писали проги? Так спросите на чем эти проги написаны, какие технологии использованы, ну есть ли там хотя бы какой-нить СКЛ сервер, и т.д. И поймете, почему говорят про цех и т.д.

Ну такие проги я не писал, да и писал оч. давно. Но в системах то до сих пор разбираюсь. Smile

Я правильно понял, срастить эти МЕС с системами сбыта (ну хотя бы с 1с Предприятие) через SQL не выйдет? То есть я не могу сбрасывать заказы по мере поступления, получая внятный срок исполнения, а могу только спустить общий план?

Сахават ():
100Х100Х100 - легко. Потому что -
1. Фиг кто разберется.
2. Там 99% разбиение минимум на 10 потоков уже (технологи - производственники постарались до МЕС).

А попробуйте один поток для разных 50 изделий с пропусками операций, карманами, многостаночностью, единичными партиями и т.д.
Во где раздоле!

Ну я имел ввиду сюда технологов не вмешивать (тот самый сферический конь в вакумме).

Вопрос еще и к Сергею , а как решается такие вещи средствами LEAN? Насколько это эффективно? Насколько я помню японцы придумали свой канбан именно от отсутствия компьютеров и могучих систем планирования производства, и именно позаказные производства их стихия (поток одиночных заказов)?
    e-mail
Сахават



: 13.06.2007
: 127

: 10, 2007 3:32 pm     : Re: Конверсионные продукты (мечи на орала)

Yosha ():
Насколько я помню японцы придумали свой канбан именно от отсутствия компьютеров и могучих систем планирования производства, и именно позаказные производства их стихия (поток одиночных заказов)?

Да вы что? Канбан - математический алгоритм. Придуман ИБМ, модернизирован Тойота.
Просто сложную вещь всегда лучше разбить на независимые части и она станет обозримой и лечге менять что-то. Вот япошки это и сделали, ОВЕЩЕСТВИЛИ алгоритм. SmileSmile

Так, пошел спать.
    e-mail
Сергей



: 29.04.2007
: 407
: Москва

: 10, 2007 4:23 pm     : Re: Конверсионные продукты (мечи на орала)

Yosha ():
... То есть я не могу сбрасывать заказы по мере поступления, получая внятный срок исполнения, а могу только спустить общий план?

Так устроено, например, у Евгения. Именно поэтому он постоянно танцует от Master Production Schedule (хотя пользуется неверной терминологией, MPS - это не объёмный план). Во многих других MES-системах таких ограничений нет, и можно принимать заказы и отправлять их в производство в он-лайне. Вроде бы, так это работает, например, у Сахавата.

Yosha ():
... а как решаются такие вещи средствами LEAN?...

Во-первых, все разумные люди нигде не заморачиваются насчёт загрузки станков. Именно поэтому в среднем по машиностроению в мире (по данным Евгения) коэффициент загрузки оборудования 0,45. А на Тойоте вообще 40%.

Во-вторых, вместо того, чтобы на всём заводе иметь один сварочный цех и при необходимости приварить ручку каждый раз тащить туда всё со всех цехов, разумные люди делают по-другому. Они прежде всего выстраивают правильный материальный поток. В частности, путём создания продуктовых линий или ячеек.

В-третьих, если поток выстроен правильно, то им легко управлять. Как известно, в любом материальном потоке может быть не более одного узкого места. Поэтому план достаточно составлять только для небольшого числа групп оборудования, а от них прокидывать верёвки на запускающие операции.

В-четвёртых, если глубоко разобраться в ТОС, то можно достичь понимания того, что выгоднее всего (с точки зрения глобальной цели коммерческой организации) быстро расшить все так называемые "тактические" ограничения (за счёт добавления дополнительных ресурсов) и оставить одно "стратегическое ограничение". В таком случае число точек управления сокращается до минимума. Например, на Тойоте эта точка всего одна - главный сборочный конвейер.

Иными словами, ситуация, при которой у вас 100 станков, 100 деталей по 100 операций, и каждая операция может быть выполнена на любом из станков - это исключительно умозрительный пример. То есть интересно с точки зрения математики, но практически совершенно бессмысленно. Хотя до сих пор иногда встречается на некоторых совковых производствах. Но им уже никакая МЕС не поможет.

_________________
Всё, что ни происходит - к лучшему!
    e-mail
Терентьев Сергей



: 02.09.2007
: 261
: Москва-Подольск

: 10, 2007 9:38 pm     : Re: Конверсионные продукты (мечи на орала)

Yosha ():
Сахават ():
Yosha ():
Сахават ():

- надо встроить имитатор
Блин. как все запущенно! Получается что черный ящик дает мне ответ, а я даже не могу проверить что было бы, если я использовал другой алгоритм?

Вы грили что писали проги? Так спросите на чем эти проги написаны, какие технологии использованы, ну есть ли там хотя бы какой-нить СКЛ сервер, и т.д. И поймете, почему говорят про цех и т.д.

Ну такие проги я не писал, да и писал оч. давно. Но в системах то до сих пор разбираюсь. Smile

Я правильно понял, срастить эти МЕС с системами сбыта (ну хотя бы с 1с Предприятие) через SQL не выйдет? То есть я не могу сбрасывать заказы по мере поступления, получая внятный срок исполнения, а могу только спустить общий план?


Сейчас 1С 8.0 Предприятие не особо нуждается что-бы его сращивали с MES ситемами. Есть опеределенные справочники - Рабочие Центры, Операции, Группы Заменяемости Рабочих Центров, Технологические Карты Производства, Графики работы, Каждому Рабочему центру назначаешь график работы. Номенлатуре илм узлу технолгическую карту где указаны операции и на каких рабочих центрах они выполняются. Показываешь системе задание на производство и она тебе показывает как загружено оборудование. Чем не MES система?

Я не сторонник MES систем и вообще не люблю религиозных споров но 1С 8.0 сейчас заваевывает и будет заваевывать сердца многих люде.
    e-mail
Yosha



: 16.04.2007
: 242
: Москва

: 11, 2007 12:11 am     : Re: Конверсионные продукты (мечи на орала)

Сахават ():

Да вы что? Канбан - математический алгоритм. Придуман ИБМ, модернизирован Тойота.
Просто сложную вещь всегда лучше разбить на независимые части и она станет обозримой и лечге менять что-то. Вот япошки это и сделали, ОВЕЩЕСТВИЛИ алгоритм. SmileSmile

Я прочитал эту легенду, кажется у Вумека. Он написал что Тоёода поездив по Америке, увидев конвеер, и внедрил эту систему у себя. Получилось просто и эффективно. Американцы в это время пытались аналитически улучшить расписания, внедряли MRP, потом в ужасе увидели что Японцы их медленно и уверенно обгоняют, несмотря на то, что у них в то время не было никаких особенных программ и компьютеров.

А то что ИБМ придулал - верю. В свое время ИБМ внедрила стандарт Token Ring. Практически канбан для компьютерных сетей. В ней что бы каждый пакет мог предваться он должен был получить. токен(жетон)

t76sv ():
Сейчас 1С 8.0 Предприятие не особо нуждается что-бы его сращивали с MES ситемами. Есть опеределенные справочники - Рабочие Центры, Операции, Группы Заменяемости Рабочих Центров, Технологические Карты Производства, Графики работы, Каждому Рабочему центру назначаешь график работы. Номенлатуре илм узлу технолгическую карту где указаны операции и на каких рабочих центрах они выполняются. Показываешь системе задание на производство и она тебе показывает как загружено оборудование. Чем не MES система?

Я не сторонник MES систем и вообще не люблю религиозных споров но 1С 8.0 сейчас заваевывает и будет заваевывать сердца многих люде.

1с уже не та бухгалтерия. Но вместе с тем несет в себе родовое проклятие учетных систем, хотя уже функционально ERP.
    e-mail
Сергей



: 29.04.2007
: 407
: Москва

: 11, 2007 12:42 am     : Re: Конверсионные продукты (мечи на орала)

Yosha ():
Сахават ():
Да вы что? Канбан - математический алгоритм. Придуман ИБМ, модернизирован Тойота. ...
А то что ИБМ придумал - верю. ...

Мне кажется, что это не так. Думаю, что Сахават путает канбан с алгоритмом выравнивания (хейдзунка) на основе метода преследования цели (goal-chasing method).

_________________
Всё, что ни происходит - к лучшему!
    e-mail
Георгий



: 15.04.2007
: 264
: Бостон

: 11, 2007 11:37 am     :

Yosha, ..., но истина дороже. Ваша ДРК не выдерживает проверку на Categories Legitimate Reservation (теперь уж как там в переводе Деттмера). Все элементы, кроме цели. И то потому, что я знаю про МЕС лишь из различающихся рассказов (как, впрочем, многие знают про ТОС). Не пойдёт

То же и о дереве. Например, переход от предпоследнего уровня к последнему (вверх) не мотивируется. Похоже, то же и внизу. А это потому, что Вы с самого начала задались некоторым планом и подгоняли под него. Не обижайтесь, строить деревья трудно.

А что это за задача - искать узкие места на мелкосерийном производстве с МЕС? Кто их ищет?

Что же за конфликт? Озвучьте его.
На мой взгляд, в Вашей формулировке Предпосылок нет конфликта.

А откуда взяты формулировки типа "МЕС система недогружает ограничивающий узел"? Значит он не ограничивающий? Тогда как узкое место (если его нет) перемещается от узла к узлу (это дальше)?
Подробнее пока не смотрел, но и так хватит.

Yosha, поясняйте или исправляйте.
Сергей



: 29.04.2007
: 407
: Москва

: 11, 2007 1:42 pm     :

Георгий ():
Yosha, ..., но истина дороже. Ваша ДРК не выдерживает проверку на Categories Legitimate Reservation ... .

Мне кажется, что в приведенном ДРК Yosha имел в виду широко известный в ТОС конфликт, а именно:
А: Эффективно управлять производством
В: Контролировать всё, везде и всегда
С: Контролировать только несколько критических ресурсов
D: Детально планировать работу всех ресурсов
D': Планировать только несколько критических ресурсов

Насчёт ДТР у меня тоже много вопросов. Прежде всего - как его строили? Сверху-вниз или снизу вверх. Если первое, то где конкретные UDE? Может, с них начать?

Кроме того, я уверен, что будет получен тривиальный результат. Дело в том, что оппоненты постоянно приводят примеры не "реальной" реальности, а "планируемой" реальности. То есть они утверждают, что если планировать производство с помощью их замечательных "MEC-систем", то будут получены нежелательные эффекты. Поэтому Core Problem, скорее всего, определяется именно этой предпосылкой. От которой сразу же переходим к приведенному выше Cloud, которое известно как разбивается.

_________________
Всё, что ни происходит - к лучшему!
    e-mail
Yosha



: 16.04.2007
: 242
: Москва

: 11, 2007 6:30 pm     :

Георгий ():
Yosha, ..., но истина дороже. Ваша ДРК не выдерживает проверку на Categories Legitimate Reservation (теперь уж как там в переводе Деттмера). Все элементы, кроме цели. И то потому, что я знаю про МЕС лишь из различающихся рассказов (как, впрочем, многие знают про ТОС). Не пойдёт

То же и о дереве. Например, переход от предпоследнего уровня к последнему (вверх) не мотивируется. Похоже, то же и внизу. А это потому, что Вы с самого начала задались некоторым планом и подгоняли под него. Не обижайтесь, строить деревья трудно.

А что это за задача - искать узкие места на мелкосерийном производстве с МЕС? Кто их ищет?

Что же за конфликт? Озвучьте его.
На мой взгляд, в Вашей формулировке Предпосылок нет конфликта.

А откуда взяты формулировки типа "МЕС система недогружает ограничивающий узел"? Значит он не ограничивающий? Тогда как узкое место (если его нет) перемещается от узла к узлу (это дальше)?
Подробнее пока не смотрел, но и так хватит.

Yosha, поясняйте или исправляйте.

Спасибо за отзыв. Надо перечитать Деттмера. Про Categories Legitimate Reservation не помню.

Собственно это была попытка уложить гипотезы и наблюдаемые эффекты в дерево в духе второй Цели.

Цель этого дерева понять действительно ли при мелкосерийном производстве под МЕС нет узкого места (размазано, или ненаходимо).
А значит и нет возможности управлять по нему.

МЕС я то же не видел, но располагал графиком загрузки, из которого следовало что все узлы системы недогружены, а производство тормозит. Под "недогрузкой узкого места" я полагал потенциальное узкое место, которое не становится узким лишь потому что так составлено расписание (как выяснилось из-за того, что заказы ожидают комплекта.

Немного не понял про уровни и мотивации.

Сергей ():
Георгий ():
Yosha, ..., но истина дороже. Ваша ДРК не выдерживает проверку на Categories Legitimate Reservation ... .
Мне кажется, что в приведенном ДРК Yosha имел в виду широко известный в ТОС конфликт, а именно:
А: Эффективно управлять производством
В: Контролировать всё, везде и всегда
С: Контролировать только несколько критических ресурсов
D: Детально планировать работу всех ресурсов
D': Планировать только несколько критических ресурсов

Насчёт ДТР у меня тоже много вопросов. Прежде всего - как его строили? Сверху-вниз или снизу вверх. Если первое, то где конкретные UDE? Может, с них начать?

Кроме того, я уверен, что будет получен тривиальный результат. Дело в том, что оппоненты постоянно приводят примеры не "реальной" реальности, а "планируемой" реальности. То есть они утверждают, что если планировать производство с помощью их замечательных "MEC-систем", то будут получены нежелательные эффекты. Поэтому Core Problem, скорее всего, определяется именно этой предпосылкой. От которой сразу же переходим к приведенному выше Cloud, которое известно как разбивается.

Спасибо!

Я для того и вывесил дерево, что мы как то не пользуемся графическими инструментами ТОС.

В общем то вы правы. Конфликт и так как ясно как разбивать. Просто захотелось уложить рассуждения в дерево.
    e-mail
Георгий



: 15.04.2007
: 264
: Бостон

: 12, 2007 9:34 am     :

Yosha ():
Цель этого дерева понять действительно ли при мелкосерийном производстве под МЕС нет узкого места (размазано, или ненаходимо).
А значит и нет возможности управлять по нему.

Yosha, спасибоExclamation
Наконец и я понял, вокруг чего вся эта траги-комедия. То-то Евгений Фролов формулирует каждый раз утверждение так: ТОС не умеет искать плавающие узкие места, а посему не работает в условиях...
Честно говоря, времени и желания не было вдуматься в это высказывание, столько других дел, а на форуме каждый раз, когда спать уже пора. Да и всё ждал, что получу ответы на простые вопросы, тогда и пойму.
Стал сегодня смотреть на Ваше дерево, чтобы покритиковать Laughing , и вдруг - см. выше. Дерево-то кривое, но плод на голову упал.

А я наконец отчётливо понял два интересных момента:
1. Узкие места плавают у месовцев (некоторых), как результат определённого типа загрузки, при имеющемся наборе ресурсов, расписания, заданного конкретной МЕС и выбранным критерием оптимизации (хотя критерий должен быть один - максимальная прибыль при наложенных ограничениях сейчас и далее, хотя выражен может быть по-разному: и потоком кэш, и стоимостью акций, ...). А далее авторы начинают, возможно успешно, с этим бороться.

2. Даже если предположить, что разработана программа, позволяющая максимально использовать производственный ресурс, даже вызывая появление плавающих УМ, то и тогда она является инструментом шага 2 (максимально использовать ограничивающий ресурс, где ограничением является всё производство), а в условиях, когда ограничение, не дай бог, не в производстве, то и вообще её роль становится второстепенной. Приплыли.
Таким образом, даже в предположении, что имеется полезный инструмент шага 2, трудно согласиться со второстепенной ролью в методологии какого-то заграничного гуру, живого да ещё и не математика.

Странно, что все на мес-форуме воспринимают появление плавающих мест, как данность, а ведь это просто результат перегрузки, когда начинают существенно сказываться и отсутствие буферной производительности, и вариабельность. То есть, вначале это виртуальные расчётные узкие места при задаваемой нагрузке, и не более того. Я-то должен был всё понять, когда первый раз, больше года назад, вызвал возмущение, написав на цфине, что не надо стремиться к полной загрузке ресурсов. Не понял, но и не знал, что тогда пропадают трудности (NP Грустный ), с которыми надо бороться.

Кроме того, так и не знаю (а кто-нибудь знает?), какова и в сравнении с чем экономическая эффективность, например, Фобоса, выраженная в единицах прибыли предприятия в целом, а не условного центра прибыли, и не в степени уплотнения потока заказов или в других подобных показателях. Причём не расчётно-теоретическая, а реальная, полученная при использовании в производстве за период времени.
По результатам применения методов ТОС есть много информации, по LEAN и 6-sigma - море, даже у участников форума, а по Фобосу или другим аналогичным?

На сегодня всё, спать.


: Георгий ( 13, 2007 2:01 am), 1
Yosha



: 16.04.2007
: 242
: Москва

: 12, 2007 11:13 am     :

Георгий ():
Yosha, спасибоExclamation
Наконец и я понял, вокруг чего вся эта траги-комедия. То-то Евгений Фролов формулирует каждый раз утверждение так: ТОС не умеет искать плавающие узкие места, а посему не работает в условиях...
Честно говоря, времени и желания не было вдуматься в это высказывание, столько других дел, а на форуме каждый раз, когда спать уже пора. Да и всё ждал, что получу ответы на простые вопросы, тогда и пойму.
Стал сегодня смотреть на Ваше дерево, чтобы покритиковать Laughing , и вдруг - см. выше. Дерево-то кривое, но плод на голову упал.

...
Я-то должен был всё понять, когда первый раз, больше года назад, вызвал возмущение, написав на цфине, что не надо стремиться к полной загрузке ресурсов. Не понял, но и не знал, что тогда пропадают трудности (NP Грустный ), с которыми надо бороться.

Кроме того, так и не знаю (а кто-нибудь знает?), какова и в сравнении с чем экономическая эффективность, например, Фобоса, выраженная в единицах прибыли предприятия в целом, а не условного центра прибыли, и не в степени уплотнения потока заказов или в других подобных показателях. Причём не расчётно-теоретическая, а реальная, полученная при использовании в производстве за период времени.
По результатам применения методов ТОС есть много информации, по LEAN и 6-sigma - море, даже у участников форума, а по Фобосу или другим аналогичным?

Вот именно так! Я то же не мог понять природу конфликта, пока не разворошил улейSmile

Что же касается окупаемости программ, то тут случается ппарадокс. Руковоители могут зажимать деньги на зарплату, на скрепки и туалетную бумагу но радостно тратят их на 2 вещи: рекламу и программы автоматизации. Роднит их одно: никто не может сказать сколько они принесли денег.
    e-mail
Сергей



: 29.04.2007
: 407
: Москва

: 12, 2007 12:11 pm     :

Георгий ():
... так и не знаю (а кто-нибудь знает?), какова и в сравнении с чем экономическая эффективность, например, Фобоса, выраженная в единицах прибыли предприятия в целом, а не условного центра прибыли, и не в степени уплотнения потока заказов или в других подобных показателях. Причём не расчётно-теоретическая, а реальная, полученная при использовании в производстве за период времени. ...

За несколько лет общения с Евгением на разных форумах я ему неоднократно задавал этот же вопрос. Обычный ответ был примерно такой: "Ну это же совершенно очевидно, что чем больше загружено оборудование в цеху, тем лучше основные экономические показатели завода. Но оптимизация прибыли и денежного потока - это не моя задача, а ERP-системы. Поэтому конкретных цифр у меня нет!" Хотя приведенная предпосылка совсем не очевидна. Более того, мой личный опыт по совершенствованию реальных производств говорит о прямо противоположном. Как правило, можно достичь существенного улучшения bottom-line measurements и одновременно снизить загрузку оборудования (фактическую, а не посчитанную с помощью замечательных отечественных "МЕС-систем").

Да, и ещё в доказательство "эффективности" применяемых подходов обычно приводится один и тот же замусоленный модельный пример уплотнения месячного плана до 20 дней. На данном форуме он, кажется, тоже представлен. Лично у меня по этому поводу всегда была только одна ассоциация: "Лихо было на бумаге, да забыли про овраги". Ясно, что из-за вариабельности и зависимости процессов такой план никогда не будет выполнен. Не говоря уже о том, что весь эффект "уплотнения" никак не связан с оптимизацией, а получен исключительно за счёт сокращения размеров партий запуска.

_________________
Всё, что ни происходит - к лучшему!
    e-mail
Yosha



: 16.04.2007
: 242
: Москва

: 12, 2007 1:13 pm     :

Сергей ():
Но оптимизация прибыли и денежного потока - это не моя задача, а ERP-системы. Поэтому конкретных цифр у меня нет!" .

К пугвицам претензии есть? (с)Райкин-Жванецкий Smile

А что касается малых партий, то опять приемы Lean доказывают эффективность...
    e-mail
Сергей



: 29.04.2007
: 407
: Москва

: 14, 2007 10:50 am     :

Георгий ():
... Странно, что все на мес-форуме воспринимают появление плавающих мест, как данность, а ведь это просто результат перегрузки, когда начинают существенно сказываться и отсутствие буферной производительности, и вариабельность. То есть, вначале это виртуальные расчётные узкие места при задаваемой нагрузке, и не более того. Я-то должен был всё понять, когда первый раз, больше года назад, вызвал возмущение, написав на цфине, что не надо стремиться к полной загрузке ресурсов. Не понял, но и не знал, что тогда пропадают трудности (NP Грустный ), с которыми надо бороться.

Кроме того, так и не знаю (а кто-нибудь знает?), какова и в сравнении с чем экономическая эффективность, например, Фобоса, выраженная в единицах прибыли предприятия в целом, а не условного центра прибыли, и не в степени уплотнения потока заказов или в других подобных показателях. Причём не расчётно-теоретическая, а реальная, полученная при использовании в производстве за период времени.
По результатам применения методов ТОС есть много информации, по LEAN и 6-sigma - море, даже у участников форума, а по Фобосу или другим аналогичным? ...

Георгий, наконец-то появился "профессиональный" ответ на Ваши вопросы. Транслирую с МЕС-форума:

"Георгий, милости просим к нашему зубному креслу. Расскажите нам, пожалуйста, как исчезает NP при повышении загрузки (или понижении, - я не въехал). Дело в том, что с этим NP мы боремся, боремся, как с утра встанем, так и боремся, но никак побороть не можем. А у Вас это получилось. Это несправедливо - держать в рукаве такой метод борьбы, за который не то, что нобелевскую, а памятник поставят прижизненно. В родном колхозе.

И по ФОБОСу поговорим обстоятельно. Я уже давно Евгению Борисовичу твержу - надо использовать передовые технологии - каждую инсталяцию его ФОБОСа надо упаковывать в хейдзунку, снабжать этот набор вантусом, дабы узкие места прочищать. А он все по-старинке работает."
(конец цитаты)

В общем по первому пункту Ваше мнение подтвердилось: ребят действительно интересует решение NP-проблемы, а не управление производством. Они просто представить себе не могут, что можно "вручную" планировать производство гораздо эффективнее, чем с помощью их замороченных "оптимальных" решений.

По второму вопросу подтвердилось моё мнение. Польза от ФОБОСа пока только планируется в виде приложения к нему вантуса. Ну что же, будем с нетерпением ждать новых релизов.

_________________
Всё, что ни происходит - к лучшему!
    e-mail
Yosha



: 16.04.2007
: 242
: Москва

: 14, 2007 1:15 pm     :

Сергей ():

В общем по первому пункту Ваше мнение подтвердилось: ребят действительно интересует решение NP-проблемы, а не управление производством. Они просто представить себе не могут, что можно "вручную" планировать производство гораздо эффективнее, чем с помощью их замороченных "оптимальных" решений.

По второму вопросу подтвердилось моё мнение. Польза от ФОБОСа пока только планируется в виде приложения к нему вантуса. Ну что же, будем с нетерпением ждать новых релизов.

Да, Сергей, ваши догадки кажется подтверждаются. NP - сложность решается либо в лоб, либо с помощью "темных эвристик".

А что касается вануза (пошел образ в народ!Широкая улыбка то тут сложнее. Евгений утверждает засоров не найти, тк они размазаны равномерно с помощью MEC и дискретного производства.
    e-mail
:   
           www.forum.mbq.ru -> Голдрат и TOC : GMT + 4
.  1, 2, 3, 4  .
2 4

 
 









Powered by phpBB © 2001, 2005 phpBB Group

File Attachment © by Meik Sievertsen