Как мне представляется, "бардак" и "конкурентное преимущество" - это несколько отличающиеся друг от друга понятия. Я не говорю о том, какое из них лучше или хуже с точки зрения автоматизации и с точки зрения бизнеса. Я лишь хочу заметить, что под "бардаком" обычно подразумевают движение в существенной степени несистематизированной, нерегламентированной, неупорядоченной информации. Если руководство предприятия намерено и впредь стрелять "приблизительно вот в том направлении", то ему не нужна автоматизированно-компьютеризированная информационная система. Потому что для процессоров пока еще не смогли придумать процессорные команды в стиле "MOV отседова примерно в северо-западном направлении плюс/минус сторона света, и до обеда". При любой автоматизации прежде всего требуется провести СИСТЕМАТИЗАЦИЮ информации - прежде всего, систематизацию НСИ. Если никакой систематизации нет, решения принимаются на интуитивном уровне по алгоритмам, которые четко не могут быть сформулированы, то никакая ERP-система предприятию не нужна . Как информация была нечеткой, так она нечеткой и останется. А ввести ее в каком-то непротиворечивом состоянии в компьютер просто не удастся.

Теперь про "конкурентное преимущество". Если слишком много решений принимается на интуитивном уровне, значит (IMHO) на самом деле никакого конкурентного преимущества у предприятия нет. Есть конкурентное отставание, потому что на предприятии нет никого, кто может сколь-нибудь полно и адекватно описать логику его работы. Если логику работы четко описать невозможно, значит и самой логики работы - НЕТ . Каждый участник процесса принимает решение, основываясь на своем неполном(!!!), представлении о том, что происходит. Особый индикатор, который отвечает на вопрос "всё ли в порядке на предприятии?" - это попытка найти честный ответ совсем на другой вопрос "насколько зависит принимаемое решение от личности того, кто его принимает?". Попытайтесь этот вопрос задать и попытаться честно на него ответить. Если вы обнаружите, что подставляя разных руководителей и/или исполнителей, вы будете получать разные результаты, значит собственно МОДЕЛЬ бизнеса вообще отсутствует. Есть лишь смутный конгломерат туманностей и облаков, глядя на которые с разных ракурсов разные участники бизнеса видят совершенно разные фигуры.

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

Посему, мне кажется, вопрос нужно ставить таким образом. Хотите по-прежнему иметь размытость-неопределенность-бардак, считая его конкурентным преимуществом - на здоровия, только об автоматизации, ради бога, заикаться не нужно. Если неопределенности нет, всё четко, ясно, алгоритм действий хорошо формулируется, НСИ систематизированы, но внедренец разводит руками - значит ERP-система выбрана неверно, функционал ее не удовлетворяет потребности заказчика.

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

UrryMcAБыло бы так все просто - программисты исчезли бы как класс.Ну, совсем они не исчезнут, но их численность уже не будет превосходить численности мух...

UrryMcAчто касается on-time обновления функционала КИС - даже поганая одинесина позволяет при известной доле мазохизма реализовать практически мнгновенную реакцию на зменение БП.Я в курсе, что там имеются периодические атрибуты. Только это далеко не всё. Попробуйте иметь разные настройки одного и того же бухгалтерского счета в разных учетных периодах (ИНФИН, кстати, это делать умеет). И это тоже далеко не все. Попробуйте иметь разные АЛГОРИТМЫ ОБРАБОТКИ ДАННЫХ для разных учетных периодов. Скажем, десять разных версий. Более чем уверен, что вы их замените на один алгоритм, в котором будет куча инструкций типа "если сегодня>даты куликовской битвы то...". Это уже не мазохизм. Это его третья степень... :)

andbaryЗдесь тема "Крик" Еще раз кричать про BPM??? Я думаю не стоит...Критика принимается. Если есть желающие поспорить на тему BPMS, предлагаю открыть новую ветку.