Информационная полнота

[Михаил_Шустер]

Мое кредо - "Успех порождают ТОЛЬКО ДЕЙСТВИЯ"
Информационные системы - это инструменты мозговой поддержки действий. Эффективные лишь при наличии собственно мозгов и желания ими воспользоваться
С точки зрения ДЕЙСТВИЯ, перечислите, например, два-три источника пользы от управленческого учета. Для затравки:

1. Обеспечивается возможность АБС-анализа ДЛЯ постановки задач отделу маркетинга
2. Обеспечивается жесткость выполнения НЕКОТОРОЙ ЧАСТИ ОПЕРАЦИОННЫХ процедур

Это действительно важно. Но сколько же источников пользы НЕ позволяет извлечь УУ!!!

[А.Б.]

Существует 2 способа быстро вносить изменения в информационную систему:
1. Иметь под рукой вменяемого программиста, который по запросу быстренько все за\перепрограммирует.
2. Заказать программисту программу, которая позволит вносить любые изменения в предметной области самому пользователю.

Долгие мытарства с вариантом 2 показали, что он сразу после внедрения начинает дрейфовать к 1... В который часто и превращается после десятка циклов.
А вот если и значально заложить разумный компромисс между кастомизируемой и дорабатываемой функциональностью, то его иногда удается удержать ... если программисты не будут злобствовать и прятать настроечные модули.

Тем кто стремится избавиться от программистов я адресую простой вопрос: ЗАЧЕМ?
Мы живем в эпоху разделения труда. Не верите - Энгельса с Каутским почитайте.

Ps. Известно что никто из любителей безразмерных программ не заказывает универсальные агрегаты, по желанию хозяина превращающиеся из дивана в унитаз, а из оного в холодильник.
Загадочно, не правда ли...

[Адепт_КАиП]

Какой обман?
А что он не объясняется математическими инструментами - мне как-то фиолетово. Шмель тоже не должен летать - а летает.

Михаил, да не переживайте Вы позря, мало ли кто с чем не согласен.
Понимаете - делайте. Доказательства - практикой :-)

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

Подумайте, что будет, если соединить, скажем, АРИС с Примаверой. Только не коряво "интегрировать", а объединить функциональность

А че тут думать, пять раз уже свистнули, делать надо. Но Примавера - "ерунда", вот лучше Сахавата возьмите, он Вам оптимизацию процессов/работ впаяет (зря он что ли к Вам всеми фибрами клеится).

[Михаил_Шустер]

Болдину:
\\\Тем кто стремится избавиться от программистов я адресую простой вопрос: ЗАЧЕМ?

Саш, да я ж всеми фибрами за. И "письма..." читал по рекомендации лично тов. Шарикова П.П. :-)
Одна беда: искажение информации при передаче. А при промышленном программировании - цепочки длинные, в каждом звене-искажение. Ты ж сам мне Гради Буча подсунул :-)

Юля,
Пожалуйста, не раскрывайте моих тайных надежд :-)
Чтобы выдать входные данные для оптимизации, их надо сначала иметь, расчистив поле оптимизаторам. Тотальное увлечение УУ создало перекос. На входе пока трудноотделимая смесь мусора с информационными дырами. Нужно время на разгребание.

[Сертаков Александр]

Михаилу Михайловичу
А при скрещивании АРИСа с Примаверой что Вы в итоге хотите получить? Я очень плохо представляю себе конечный продукт, хотя и то, и другое "щупал". Или это просто пример? =)

Адепту
> Но Примавера - "ерунда"
За слова ответите? Доказательства в студию!

[Михаил_Шустер]

Саш, что толку прочитать готовый ответ к задаче?
Это не "просто" пример. Попробуй сам, она того стоит.
Всю необходимую для решения теорию ты знаешь.
Я выложу решение, но позже

[Сертаков Александр]

Михаил Михайлович, судя по всему, получится некий мутант, жуткий, но симпатишный. По хорошему говоря, если вкратце, это будет продукт, очень схожий с продуктом Долженко Валерия. Прописываем классификаторы и справочники, рисуем модельку, протягиваем взаимосвязи, устанавливаем требования к формам, получаем ИС для управления проектами и многого другого...
Здесь самое главное будет - гибкость. Но неужели это же самое нельзя реализовать в Искре?

[Михаил_Шустер]

Гы :-)
Дык в ней же, родимой, и реализовано. Только намного дешевле
АРИС и РМ-продукты знают все (ну, почти). Искра пока внедрялась, как платформа для разработки ЕРП, МРП-систем и как готовые прикладные решения. Новая функциональность на сайте пока не выложена; внедрим на АЭС-поместим победную реляцию.

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

Для красоты. Есть множество различных задач, от стратегии, разведки до топопривязки, которые заканчиваются стандартным:

Командир: -Стрелять первому. Осколочно-фугасным. Основное направление левее 20. Прицел 160. Один снаряд. Огонь!"
Наводчик: -Выстрел!
Дальномерщик: -Дальше двести. Левее двадцать
Командир: -Стрелять батарее. Основное направление правее 0.02. Уровень меньше 0.04. Веер сосредоточенный. Очередь!

"Множество разных задач" - это АРИС сотоварищи плюс прикладные задачи
"Стрелять первому" - это РМ

ЗЫ. Примавера-хороший продукт. Спайдер значительно превосходит ее по скорости расчетов и возможностям оптимизации, но на мой взгляд уступает в наглядности.
Управление портфелями не нравится ни в одном продукте.

[Евгений]

... Примавера-хороший продукт. Спайдер значительно превосходит ее по скорости расчетов и возможностям оптимизации, но на мой взгляд уступает в наглядности.

Михаил,
а Вы никогда не задумывались, почему ни Примавера ни Спайдер, как правило, не применяются для составлении производственных расписаний на машиностроительных предприятиях? - А ведь, казалось бы, нет никаких препятствий...

[hilton]

разный подход к понятию Ресурса. Для одних это жизненная сила, для других - на кого спихнуть.

[Carina]

Карина, если Вас интересует готовое решение - обращайтесь по мылу
По указанным Вами требованиям совсем не требуется программист по:
1. вводить новые понятия (объекты) в ИС
2. увязывать их с уже существующими
4. управлять ими, т.е. их поведением в рамках БП и собственно БП

Некоторые элементарные навыки программирования требуются по:
3. вводить новые правила обработки
5. обеспечивать пользователей соотвествующим интерфейсом.

Для очень большой задачи на очень большом предприятии, пункты 3 и 5 заняли 2 дня совместной работы постановщика и программиста. Но для улучшения функциональности (полноты) на 90% требуется работа постановщика: структурирование объектов в иерархических классификаторах, расширение библиотек целей, процессов, шаблонов.

Ps. "Постановщик" = консультант (внутренний или внешний)

Спасибо, Михаил. Как думаете, задавала бы я такие вопросы, если бы не имели мы уже своего решения ? Но согласна с Сахватом, если бы все было так просто ) ...

[Carina]

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

Не верьте Михаилу, это обман :-) хоть и из лучших побуждений

Юлия, а почему Вы решили, что я занимаюсь этим всем на словах? А кейс средства к этому не имеют большого отношения. Хотя можно кое-что использовать, не без этого ... И формальной теорией занимаюсь, и монографии выпускаю и статьи печатаю и среду разрабатываем .. Именно с теории и начался этот раздел - теорию на помойку не стоит выбрасывать .. И прекрасно представляю размеры и объемы задач и не собираюсь, спасать весь мир, предпочитаю ограничться своей информационной средой и сделать там по возможности многое, что считаю нужным (это вовсе не равно всему, что я выше написала). Мы идем по спирали. Но, очевидно, что никогда не дойдем, от программистов нельзя избавиться, согласна с АБ. Но никто и не собирается .. речь о другом. Речь о смещения акцентов с сопровождения ПО на разработку нового. А сопровождение занимает слишком много ресурсов и нет времени заниматься новым. Вот эту задачу мы и решаем, хотя и она, конечно, не будет никогда решена окончательно. Наша цель - уменьшить затараты на сопровождение.

[Сертаков Александр]

Евгений!
> Вы никогда не задумывались, почему ни Примавера ни Спайдер, как правило, не применяются для составлении производственных расписаний на машиностроительных предприятиях?
Евгений, Вы никогда не задумывались, почему ни молоток, ни кувалда, как правило, не применяются для вворачивания шурупов в стенку?

[Сахават]

Евгений!
> Вы никогда не задумывались, почему ни Примавера ни Спайдер, как правило, не применяются для составлении производственных расписаний на машиностроительных предприятиях?
Евгений, Вы никогда не задумывались, почему ни молоток, ни кувалда, как правило, не применяются для вворачивания шурупов в стенку?

А как насчет "создать объекты ИС и задавать взаимосвязи и (создать)управлять БП"? Александр, не спешите.

[Михаил_Шустер]

почему ни Примавера ни Спайдер, как правило, не применяются для составлении производственных расписаний на машиностроительных предприятиях

Потому что именно для этого существуют MES-системы :-)
Можно ведь спросить и: "Почему директор не встает к станку?"
Каждому - свое. Системы специализируются, как люди. Нет одной системы, перекрывающей всю потребность предприятия.
Я вижу вот какую дыру: есть хорошие системы для бухгалтеров, конструкторов, технологов. Но вместо систем для директоров, есть только системы для аналитиков. Это два очень сильно разных человека.
Не знаю насчет "ситуационной комнаты", может это и для директоров. Но я только слышал, а не видел.

[Оксана Яковлева]

Евгений!
> Вы никогда не задумывались, почему ни Примавера ни Спайдер, как правило, не применяются для составлении производственных расписаний на машиностроительных предприятиях?
Евгений, Вы никогда не задумывались, почему ни молоток, ни кувалда, как правило, не применяются для вворачивания шурупов в стенку?

Ой, Саш, Я применяла..Просто супруг оооочень долго не делал, то что Я попросила (повесить картинку)... Поэтому Я взяла молоток и гвоздик... ну в общем от стены почти ничего не осталось...Мой супруг сидя в кресле за этим всем наблюдал... Но когда Я случайно устроила короткое замыкание по всему подъезду и меня шарахнуло током с вызовом скорой... он усмехаться перестал и повесил любимую картинку (ну ес-но стену отремонтировал). Правда до сих пор смеется по-поводу Моих усилий пробить несущий железобетонн посредством молотка и гвоздика(но справедливости ради надо заметить, что молоток и гвоздики надежно спрятал) ...

[Михаил_Шустер]

Бетонную стену безразличия нельзя пробить гвоздиком MES-систем
Их место - тонкая работа с материалом. Часовая отвертка, нивелир, отвес...
"Молотком" является ТОП. Ему нужен мощный пробойник
Простой, грубый, надежный. И он у него есть пока в виде самого же себя
Перфоратор же ERP дорогой, капризный и в розетку не влазит
Вот мы с Валерой (hilton) и придумали "Решатель", который трехкучечным методом осуществляет сексуальный принцип управления
Вся сложность-в "механизме наведения"

[Евгений]

Потому что именно для этого существуют MES-системы :-)

Михаил, я задал этот вопрос неспроста. (кувалду А.Сертакова оставим пока в покое). Я переформулирую свой вопрос иначе:
В чем отличие итоговой картинки, полученной игроком в тетрис, от аналогичной картинки (множество исходных собираемых элементов одно и тоже), полученной игроком в пазл? (мы как-то вскользь уже касались этого вопроса).
А междут тем, если вдуматься, мой вопрос имеет непосредственное отношение и к теме данной дискуссии (информационная полнота)
и к вопросу различия планировщиков, используемых в MES, от планировщиков PM, ярким представителем которых являются и Примавера и Спайдер.

Почему я, вообще, задаю такие странные вопросы? А чтобы внести некоторую ясность в обсуждение (а также, возможно, дать пищу для ума лицам, знающим принципиальные отличия шурупов от гвоздей ).

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

[Евгений]

Евгений, Вы никогда не задумывались, почему ни молоток, ни кувалда, как правило, не применяются для вворачивания шурупов в стенку?

Александр, шуруп завинчивается отверткой, как правило, по часовой стрелке, а кувалда и молоток используются при забивании гвоздей.
Ко мне еще есть вопросы?

[Михаил_Шустер]

Евгений, я-то с должным почтением отношусь и к Вам, и к Mes :-)

Mes - система точного наведения; тонкая, сложная, динамическая
Но ей нужна система грубого наведения, чтоб поймать в оккуляр нужную цель
Грубая система и должна работать грубо, т.е. в статике, с пазлами. Иначе она будет слишком сложной
Системы не могут конкурировать, т.к. входят в одну надсистему
У них разный уровень иерархии пользователей

Т.е. разница между ними не как между горными и водными лыжами, а как между лыжами и канатной дорогой. Одно без другого - разве что, для экстремалов :-)

[Евгений]

Евгений, я-то с должным почтением отношусь и к Вам, и к Mes :-)

Mes - система точного наведения; тонкая, сложная, динамическая
Но ей нужна система грубого наведения, чтоб поймать в оккуляр нужную цель
Грубая система и должна работать грубо, т.е. в статике, с пазлами. Иначе она будет слишком сложной
Системы не могут конкурировать, т.к. входят в одну надсистему
У них разный уровень иерархии пользователей

Т.е. разница между ними не как между горными и водными лыжами, а как между лыжами и канатной дорогой. Одно без другого - разве что, для экстремалов :-)

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

На самом деле, Александр Сертаков угадал правильно суть проблемы в своем примере с кувалдой и шурупом. - если стоит задача забить быстро, например за 5 секунд, то рука потянется вовсе не за отверткой, хотя мы и держим не гвоздь, а шуруп...
Алгоритмы в MES я бы сравнил с шахматистами, играющими блиц-турнир, в то время как алгоритмы от PM можно было бы сопоставить с игроками в классические шахматы. Заметьте, что доска и фигуры на ней и в том и в другом случае одинаковые, а принципы игры (при одинаковых правилах) существенно различаются. Так, в задачах управления проектами все работы доступны для оптимизации, а в MES никто толком заранее не знает, случится или нет брак на следующей операции, выйдет ли станок из строя, поступит ли, вообще, комплектующие в момент сборки узла... В общем MES предназначена для оптимизации бардака или, если сказать по-умному, для работы в условиях неполной информации. Ясно, что в таких условиях об управления проектом говорить можно лишь с очень большой натяжкой (я не говорю уже о том, что время в MES - это еще не главный критерий оптимизации, как например в РМ).

К чему все это? Надо тщательно разобраться не только в постановке оптимизационной задачи, но и учитывать характер исходных данных (динамика или статика). Оказывается, что это важно для получения практического результата.

[Михаил_Шустер]

Статика-та же динамика, только у нее размерность Т больше :-)
Динамика проще статики в том смысле, что изменения видны невооруженным глазом (сравнить вопрос жены: "Я правда похудела?"). Когда производство лихорадит-это видят все. Когда зарождаются условия для лихорадки производства-это видят лишь отдельные Кассандры, которых "как и очевидцев, во все века сжигали на кострах"

\\\в задачах управления проектами все работы доступны для оптимизации

Вы слишком хорошо думаете про управление проектами :-)
На самом деле, главный враг РМ - неопределенность. Ее почти нет только в хорошо тиражируемом проекте, приближающемся к операционной деятельности-т.е. когда деятельность уже фактически не есть РМ. Неопределенность в Mes - быстрее, но в РМ - губительнее.

"Блиц" - это, конечно, ближе к искомому. Мир меняется все быстрее, требуя того же от организации. И в нем на первом месте - "угадать" направление изменений. В поддержку чего, на мой взгляд, и нужно акцентировать весь аппарат рационалистической поддержки.
Но это не означает, что развитие АСУП в этом направлении должно подавить развитие других. Система поддержки должна быть (пардон) сбалансированной :-)

[Сертаков Александр]

> Александр, шуруп завинчивается отверткой, как правило, по часовой стрелке, а кувалда и молоток используются при забивании гвоздей.
Ко мне еще есть вопросы?

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

> Так, в задачах управления проектами все работы доступны для оптимизации, а в Mes никто толком заранее не знает, случится или нет брак на следующей операции, выйдет ли станок из строя, поступит ли, вообще, комплектующие в момент сборки узла...

Просто, Евгений, Вы никогда нормально не работали с Примаверой. При значительной детализации, до часов и даже минут (а Примавера способна работать таким образом) сходство очень близкое. И проблемы брака точно также остро встают, и проблемы поставок комплектующих. А уж то, как часто Заказчик выполняет свои обещания по поставкам сырья и материалов - это будет боевик покруче любых проблем с использованием Mes.
Неопределённость даже в медленном, весьма нестремительном проекте строительства трубопровода есть не в меньшей степени, чем при работе с большим количеством небольших партий - только представьте срыв поставки техники, необходимой для сварки труб на 4-5 месяцев. Там таааакое начинается =)))

Или, на Ваш взгляд, при строительстве трубопроводов брака не бывает?

[Евгений]

Или, на Ваш взгляд, при строительстве трубопроводов брака не бывает?

Шуруп завинчивается отверткой, как правило, по часовой стрелке...

[Владимир Либерзон]

Спайдер успешно используется на ряде предприятий для составления производственных расписаний. Я не утверждаю, что он под это заточен. В частности, в пакете пока не моделируются переналадки станков. Там, где это не слишком существенно, пакет используется и приносит пользу.

Михаилу Шустеру: интересно, что именно не нравится в том, как поставлено управление портфелями проектов в Спайдере.

[Евгений]

Спайдер успешно используется на ряде предприятий для составления производственных расписаний. Я не утверждаю, что он под это заточен. В частности, в пакете пока не моделируются переналадки станков. Там, где это не слишком существенно, пакет используется и приносит пользу.

В.Либерзону, А.Сертакову, М.Шустеру.
Коллеги, конечно, если исключить динамику процесса, т.е., к примеру, сфотографировать расположение фигур на шахматной доске, то трудно сказать, что это за партия: блиц-турнир или классические шахматы. То же самое можно сказать о картинке, собираемой в тетрисе или пазле... Поэтому в нашем случае, говоря о разнице между MES-планировщиком и РМ, следует обратиться к другому не алгоритмическому, а более наглядному аргументу (как говорил Карл Саган, «чрезвычайно важные утверждения требуют чрезвычайно убедительных доказательств» ).

Коллеги, система "Спайдер" - одна из наиболее сильных систем, существующих ныне на рынке, среди программ, относящихся к Project Management (PM). И безусловно, существуют типы производств, где использование РМ вполне оправдано. Однако, следует заметить следующее:

1. В основе подавляющей части оптимизационных алгоритмов, относящихся к РМ, лежит задача минимизации общего времени обработки N партий деталей на М станках, известной в литературе, как (N*M)-задача Беллмана-Джонсона. Однако в реально действующих производствах минимальное время уже не является (скорее, далеко не всегда является) основным критерием составления производственных расписаний.

2. Известный специалист в области теории расписаний М. Смит (M.Smith), отмечает, что около сотни человеко-лет уже затрачено на решение задачи составления производственного расписания с минимальным временем выполнения планового задания. Однако он не знает ни одной компании или фирмы, которая бы использовала такое расписание при управлении своими производственными подразделениями [Smith M., Panwalkar S., Dudek R. Flowshop sequencing problem with ordered processing time matrices. // Manag. Sci., 1975, 21, N5, 544-549].

3. "Минимальное число переналадок" (типичный критерий в MES, см. http://www.mesa.ru/phpbb/viewtopic.php?t=10 ) в машиностроении это вовсе не сокращение времени простоя оборудования, как может показаться на первый взгляд. Каждая переналадка станка обусловлена перебазированием (переустановом) детали, сменой режущего и вспомогательного инcтрумента, сменой всех применяемых в технологической операции приспособлений. Все это влечет за собой потерю точности обработки. Поэтому, обеспечивая надлежащее качество изготавливаемых изделий, производственники идут по пути минимизации числа переналадок, т.е. минимального числа перемещений деталей в пределах группы взаимозаменяемого оборудования (не путать с минимизацией суммарной длительноcти этих переналадок).

4. ....

Есть, конечно, и другие аргументы, но пока, я думаю, достаточно первых трех...
Некоторые подробности см. http://www.e-xecutive.ru/discussions...50583_1145712/

[Владимир Либерзон]

Евгений,
Спайдер не претендует на звание Mes-системы, однако на ряде производств его критерии устраивают, а ограничения не столь существенны.
На другом форуме я уже высказывал свои соображения, которые повторю здесь.
Да, в управлении проектами критерием успеха является минимизация сроков выполнения планируемой совокупности работ. Это объясняется просто - проект при этом заканчивается и соответственно заканчиваются накладные расходы, аренда оборудования и прочее. То есть это и экономически оправданно. Критерий означает минимизацию простоев ресурсов.
Однако в производстве накладные расходы не снизятся при выполнении того же плана быстрее, если есть запасы по мощности. Если месячный план выполнить за 20 дней, то цех будет стоять оставшееся время, если отсутствуют заказы.
Потому критерий минимизации простоев оборудования эффективен тогда, когда мощности полностью загружены и появляется возможность теми же ресурсами сделать больше и получить дополнительную прибыль.
Ну и к тому же задачи на самом деле различаются. В Спайдер планы из других систем (например, Erp) не спускаются. Он способен оптимизировать (по критерию минимизации простоев) деятельность завода с учетом ограничений по наличию и потавкам материалов (заготовок), наличию и производительности станков и специалистов, срокам выполнения заказов и т.д.
Но он (пока) не умеет моделировать переналадки, транспортировки, а потому в тех производствах, где они занимают существенное время, его полезность сильно снижается.
То есть его можно использовать (и его используют!), но не для всех типов производства.