Roman BrunetsНапример, при заказе А мы задействуем ресурс Б. На
выполнение заказа А у нас есть два дня. Если завтра будет еще один заказ
А, то дешевле (на порядок) задействовать ресурс Б завтра. Но, если на
завтра заказа А не будет, то загруженность ресурса Б делают выгодным его
использование сегодня.Подобные задачи решаются множеством ERP-систем. Только все эти "если-то" должны быть представлены именно исходными предпосылками - то есть в виде причин, из которых и следует вывод, что "дешевле (на порядок) задействовать ресурс Б завтра". Для этого необходимо ввести в систему время и стоимостные характеристики времени переналадок оборудования (например), а также использовать стратегию планирования "под прогноз + под заказ". "Завтра" - это прогноз. "Сегодня" - это заказ. А ERP-система уже сама разберется, как лучше задействовать ресурсы, если только она способна решать оптимизационные задачи.

Roman BrunetsРешение принимается на основании опыта и вещей, к логике бизнеса не имеющих никакого отношения, как-то личная просьба заказчика.Для работы в подобном стиле НЕ НУЖНА ERP-система и вообще автоматизированная система. Если предприятие имеет желание и дальше принимать решения "на основании личного опыта", то вообще не понятно, с какой стати оно озаботилось вопросами автоматизации. Почитайте "Цель" Голдратта. Там приведен очень живописный пример того, как предприятие от работы в режиме "тушения пожаров", в котором все нервничают, орут друг на друга, начинают делать одно, потом вдруг бросают и хватаются за другое (потому что поступила внезапная команда сверху). После реструктуризации системы управления завод резко сокращает материальные запасы, незавершенку и объемы готовой продукции, пылящейся на складе, со сроков выполнения заказов, измеряемых месяцами (до полугода) переходит к срокам в 2 недели - и к тому же одновременно резко увеличивает процент выполненных заказов в срок. Работники начинают работают спокойно, без нервотрепки и авралов. В конце книги на завод на вертолете прилетает президент крупного заказчика, которого они просто спасли, выполнив объемный заказ в такие сроки, которые он считал нереальными. Он специально прилетел пожать руку каждому рабочему, полагая, что завод три раза вывернулся наизнанку и отложил все остальные заказы. А на самом деле завод работал в штатном режиме и никаких заказов в сторону не откладывал. Там есть потешная сценка, где двое рабочих переглядываются и с удивлением спрашивают про прилетевшего на вертолете босса заказчика "чего это c ним?" "не знаю... наверное мы сделали что-то особенное..." (пожимает плечами). К чему всё это? К тому, что "личные просьбы заказчика" могут радикально изменять план работы только в режиме "тушения пожаров", и сам факт работы по схеме "тушение пожаров" говорит о том, что организация работ очень далека от идеала. И есть смысл подумать о причинах возникновения этих самых пожаров, а не об эффективности их тушения.

Roman BrunetsНе, конечно, по взрослому нужно потратить по полчаса на планирование выполнения заказа, который выполняется за 10 минут...
Posted via ActualForum NNTP Server 1.3Так вы не хотите тратиться на планирование? Я так и не понял, зачем вы приобретали Entarprise Resourse Planning ?

andbaryЭххх... Если бы BPM стоил столько, все было бы просто чудесно... Unify NXJ - 10'000$ на одно предприятие.
MS BizTalk Server - 6'500$ на одно предприятие.
Мне кажется, эти цены существенно ниже стоимости ERP-системы.

iscrafmGarya, Вы наверное нарочно забыли отметить, что это деньги в дополнение к ERP системе, хотя действительно меньшие. Так называемые BPM задачи, решаемые так называемыми ERP системами - не решают. Предлагая новый фронт, необходимо обеспечить в первую очередь тылы .Нет, не нарочно. Но замечание действительно существенное. В BPM не встроены модули синхронного планирования или другие модули, реализующие математически сложные оптимизационные задачи. Посему есть возможность раскинуть мозгами - а нужно ли приобретать ERP-систему, которая безуспешно пытается охватить собой всё мироздание, уплатив за все ее завитушки и трещинки круглую сумму, или взять только некоторые модули, которые действительно необходимы, и связать их с остальной бизнес-средой с помощью BPMS. Я не утверждаю, что именно так и нужно поступать всегда и везде (может просто не получиться). Но этот вариант нельзя сбрасывать со счетов, о нем обязательно нужно подумать, если встал вопрос автоматизации управления производством. По крайней мере, он таит за собой еще тьму всяких перимуществ кроме экономии на стоимости ERP-системы. Например, возможность завязать CAD/CAM с ERP не только для одностороннего обмена информацией, а включения их в цикл, когда изменения в конструкторскую и технологическую документацию вносятся и после запуска производства, и с учетом критериев, закладываемых отделом снабжения (а ведь их требуется учитиывать еще на стадии разработки), и множеством других взаимных влияний, закольцованных в большую и неудобную кучу обратных связей, которые стараются "пропустить мимо ушей", делая интеграцию между ERP и CAD/CAM, потому что реализовать все "хотелки" оказывается слишком сложно.

andbary+ Стоимость спеца (ов) который с этим ПО справится (оценить его (спеца) эффективность работа не для слабонервных).Мы скачали демку Unify, попробовали ее руками и поняли, что никаких особенных спецов для работы с нею нам не требуется. Попробуйте сделать это сами, чтобы в этом убедиться. Мне кажется, Вами движет страх перед неизведанным, и размер этого страха существенно больше, чем реальные причины для страха.

andbary+ Стоимость изменений компании (стоимость перестройки (и гемороя)).Я рад, что в понимании этого нюанса у нас единое мнение. Изменения стиля управления компанией не может происходить без коренной ломки мозгов. Только это не совсем "стоимость", это в большей степени "риск". Причем, один из наиболее существенных. И он не имеет никакого отношения к вопросам IT. Это вопрос менеджмента в чистом виде.

iscrafmЧто такое эта изменчивая и гибкая функциональность? В сухом остатке - запуск определенных процедур в зависимости от условий. Для этого не нужна BPM система. Любые case-системы содержат подобные функции.Вы забыли еще один нюанс. Изменения должны производиться без остановки множества уже запущенных длиных транзакций. Изменения могут вноситься с такой скоростью, что пока завершится первая длиная транзакция, схема бизнес-процесса может измениться несколько раз . Таким образом, в системе могут присутствовать одновременно множество транзакций, выполнение которых происходит по разным схемам, точнее, по разным версиям одной схемы. И какие case-средства позволяют вносить изменения таким образом, чтобы не прерывалось выполнение текущих транзакций и чтобы удобно и единообразно можно было мониторить процессы, выполняемые по разным схемам и по разным версиям одной схемы?

UrryMcAТак. Вот здесь поподробнее...Попробую... :)
1. Вы нарисовали схему бизнес-процесса (например, "обработка заявки клиента")
2. Ввели полученную схему в работу
3. Поступило 100 заявок, которые отправлены на обработку, но еще не обработаны
4. Аналитик обнаружил некоторые недостатки уже запущенной схемы, и внес в нее изменения (например, исключил лишние звенья)
5. Поступило еще 60 заявок, которые будут обрабатываться по новой схеме, ранее поступившие 100 обрабатываются по старой схеме
6. Аналитик выявил сбой в работе схемы, внес в нее дополнения в стиле "обработка исключения"
7. Поступило еще 70 заявок
... на этот момент в обработке находятся 100+60+70=230 заявок, выполняющихся по трем разным версиям схемы бизнес-процесса.
8. И вот, наконец, выполнились первые 10 заявок!
9. Тут аналитик придумал, как можно ЕЩЕ улучшить схему бизнес-процесса, и опять внес в нее изменения.
10. Поступило еще 30 новях заявок
...на этот момент в обработке находятся (100-10)+60+70+30=250 заявок, выполняющихся уже по четырем разным версиям схемы одного бизнес-процесса
и т.д.

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