Согласен с Guest_1234. Синхронизация справочника ТМЦ конкретного покупателя с конкретным поставщиком предполагает, что данный конкретный покупатель ЗАВЕДОМО будет приобретать ТМЦ у данного конкретного поставщика, даже если существует другой поставщик, предложивший более качественные и дешевые ТМЦ, справочник ТМЦ которого НЕ синхронизирован со справочником ТМЦ данного покупателя. Для того, чтобы покупатель не ограничивал себя и намеренно не исключал положительного действия рыночных механизмов, необходимо, чтобы ВСЕ поставщики еще синхронизировали свои продукты между собой, используя какие-то НАД-организационные стандарты, разработанные некими ассоциациями, в которые входят множество конкурирующих поставщиков.

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

Есть еще один нюанс. Два разных завода производят одну и ту же продукцию. Как вы полагаете, она должна иметь одно и то же обозначение? Но как же быть с тем фактом, что качество продукции, поставляемой одним заводом, существенно выше, чем поставляемой другим? Я понимаю, что покупатель может разграничить эту информацию в разрезе поставщиков, но только в том случае, если он приобретает продукцию напрямую на заводах, а не у диллеров, перепродавцов и т.п. Но как быть, если один и тот же перепродавец торгует продукцией обоих заводов, а покупатель намерен приобрести продукцию конкретного завода? Параметры качества могут быть связаны не только с производителем, но и с перепродавцом (некоторые из них, представьте себе, пытаются мухлевать, пытаясь выдать один товар за другой). В этих условиях возможность создания единого глобального классификатора ТМЦ мне кажется весьма проблематичной.

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

Guest_1234Мы нарываемся на ограничения в зарубежных разработках при попытке выполнить проводку прошлым периодом или еще хуже - будущим, исправить приходную/расходную накладную или платеж задним числом и пр. Это ограничения НЕ BPMS. Это ограничения приложений, которые BPMS объединяет. Разумеется, BPMS не является волшебной палочкой. Он не сможет устранить проблемы, проявляющиеся ВНУТРИ задействованных в бизнесе приложений. Но он может объединить эти приложения в единую систему и при этом реализовать ту часть функционала, которая выходит за пределы каждого из имеющихся приложений.

Guest_1234Рассмотрим следующую ситуацию: в заявке на приобретение материала искажено его наименование (сорт, типоразмер, марка, ...).У нас заявки принимаются тремя способами:
1. В произвольном виде и формате (это может быть, например, сообщение, полученное по электронной почте в произвольной форме, или факс)
2. В виде заполненного тематического опросного листа
3. В виде перечня конкретного оборудования, выбранного на нашем сайте из каталога.

Во всех случаях запускается "проработка заявки", первый шаг которой - связаться с клиентом и уточнить как мимнимум цели, для которых приобретается оборудование. Как это ни удивительно, наиболее предпочитаемым для нас является не 3-й вариант, а 2-й. Именно он позволяет заведомо получить ответы на основную часть вопросов. По 3-му варианту очень часто наши клиенты делают неправильный выбор для имеющихся условий и требующих решения задач. Хорошо, если это лишь не самый оптимальный выбор. Но зачастую выбор бывает просто ошибочным. Клиент просит поставить оборудование, совершенно не то, которое ему на самом деле нужно. Разумеется, по варианту 1, происходит наиболее длительный диалог с целью уточнения потребностей клиента. Как правило, наш сэйл-менеджер отправляет опросный лист, то есть, переводит диалог в русло варианта 2. Вариант 3 для нас - самый проблематичный. Клиенту врядли сможет понять, с какой целью ему выслали опросный лист, если он уже сделал конкретный выбор. Поэтому наши сэйл-менеджеры стараются очень акуратно и ненавязчиво задать основные вопросы опросного листа, чтобы убедиться, что клиент действительно не ошибся. Потому что если он выявит ошибку уже после приобретения, могут пострадать наши отношения между продацом и клиентом.
Поэтому вне всякой зависимости от формы заявки первым шагом бизнес-процесса яваляется связь с клиентом и уточнение требовний. Не могу сказать, что именно BPM позволяет наиболее эффективно решить эту задачу. Но, в общем-то, позволяет. И это наиболее важный фактор, с помощью которого резко уменьшается веротяность ошибки в заявке.

Второй фактор - процедура согласования. В ответ на заявку с нашей стороны ОБЯЗАТЕЛЬНО формируется встречное предложение. В нем детально прописываются все основные характеристики и особенности условий эксплуатации оборудования, фигурирующего в предложении, помимо цены и сроков поставки. Если клиент утверждает предложение, ему выписывается счет и/или спецификация к договору (если клиент постоянный). Этот этап позволяет устранить часть ошибок, не выявленных на первом этапе.

Третий фактор - процедура оформления документов. Документы обычно формируем мы сами на основании утвержденного покупателем предложения. Это исключает появление всякого рода опечаток или недомолвок.

Таким образом, эта проблема решается грамотной организацией бизнес-процесса.

Guest_1234Вопрос: чего ожидать от BPMS в условиях, когда не все хорошо и стабильно, когда имеются ошибки оператора, кладовщика, нач. ОТК, ген. директора ...В любом случае не следует ожидать от BPMS решения абсолютно всех проблем мироздания. Некоторые проблемы он помогает решить. Преимущественно, это проблемы взаимодействия большого числа приложений и людей, реализации части бизнес-процесса за пределами имеющихся приложений, реализация контроля бизнес-процесса на фазах его выполнения по каждому конкретному факту его инициации. Если бизнес-процесс допускает возможность ветвлений (вариаций), то вразумительно ответить на вопрос, почему и каким именно образом была достигнута конкретная фаза бизнес-процесса. Позволяет отследить отклонения, ошибки, нарушения сроков и иные ситуации, когда что-то "пошло не так", и акцентировать внимание руководителей именно на решении проблем а не на тотальном отслеживании всего и вся, на что физически может не хватать времени и прочих ресурсов.

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

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

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

2 проц. В BizTalk ACID-транзакции могут использоваться лишь на одном элементарном шаге бизнес-процесса, для которого действие рассматривается как атомарное . Оно либо целиком происходит, либо целиком не происходит. Обеспечиваются такие транзакции НЕ BizTalk-ом, а внешними инстументами. Например, СУБД, к которой BizTalk обратился с помощью SQL-запроса, в котором присутствует инструкция BEGIN TRAN. Или с помощью внешнего приложения, которое своими средствами организует ACID-транзакцию. То, что традиционно в BizTalk именуется "транзакцией", не имеет к требованиям ACID никакого отношения и, как правило, для подчеркивания этого факта именуется " длинной транзакцией". Которая может длиться сутками, месяцами, годами.
Если Вы, уважаемый проц, сколь-нибудь знакомы с принципами грамотного построения информационных систем с использованием СУБД, Вам должно быть известно, что ACID-транзакция, которая организуется для обеспечения целостности информации, накладывает существенные ограничения на методы обраотки информации. На "блокировочниках" она может на длительное время заблокировать доступ к ресурсам, на "версионниках" может породить разные варианты одной и той же информации в разных сессиях. Те, кто имеют дело с СУБД, стараются ограничивать рамки одной ACID-транзакции одним законченным движением пользователя. Считается недопустимым и безграмотным использовать такие транзакции, которые пользователь может открыть и забыть закрыть (например, вызвали сотрудника на срочное совещание или пошел кофейку попить). Я уже не говорю о транзакциях, в которых могут быть задействовано НЕСКОЛЬКО человек - они еще более недопустимы.
В этом свете Ваши замечания по поводу того, что подобные транзакции "обязаны быть" выглядят несколько странными... Я уже не говорю о том, что по жизни очень многие процессы по своей природе не могут быть откачены. Попробуйте засунуть бумагу в шредер, а потом "откатить" эту операцию. Или что-то более близкое к информационным техноололгиям - попробуйте распечатать на бумаге документ, а потом "откатить" это распечатывание. :)

процшаг 1. КИС1 пытается оплатить счет, видит что в КИС2 денег нет и делает откат. (а если деньги есть, то их резервирует)
шаг 2. Оплата откладывается
шаг 3. все довольныЕсли КИС1 пытается сделать шаг 1 в пределах одной ACID-транзакции, то и наздоровье, пусть делает, она прекрасно впишется длинную транзакцию - никаких проблем не вижу. Если вы полагаете, что BPMS должна уметь сначала что-либо делать, а лишь потом выяснять, можно ли было это сделать с возможностью " отката ", то я не понимаю оснований, на которых она это "должна уметь". Лично я никакой необходимости в этом не усматриваю, просто исходя из природы вещей. BPMS оперирует понятием "бизнес-процесс", который оперирует событиями, объектами, находящимися ВНЕ себя, для которых невозможно установить "уровни изоляции транзакций", "объектные модели" которых не согласованы, и нет никакой гарантии, что выполненные на любом шаге действия являются обратимыми. Если они действительно являются обратимыми, то бизнес-аналитик в любом случае должен предоставить в систему информацию о том, КАКИМ ОБРАЗОМ они обратимы, то есть прописать процедуру отката самостоятельно по шагам.
Может быть, вы ститаете, что BPMS обязана умееть читать мысли?

процпочему-то весь мир движется именно в этом направлении наверное вас и др. не читал (банальный пример sap/r3)А что, в этом "банальном примере" имеется встроенная CAD-система с 3D-моделированием? И вы сможете задействовать этот "банальный пример" для связки с банком вместо той системы "клиент-банк", которую банк предоставляет всем остальным клиентам? И вы сможете также в электронной форме сформировать файлы отчетности для налоговой инспекции в том формате, в котором они ожидаются ответной частью программы "Баланс-2" в формате, который кроме фирмы фирмы "Овионт" более никому не известен? Потрудитесь пожалуйста привести менее "банальный" пример (одного достаточно), в котором все эти проблемы решены в рамках единой КИС.

процвсе ваши примеры не по теме - это интерфейсы с чужими системами - там свои методыЧем "свои" системы отличаются от "чужих"? Вы разве сами разработали SAP/R3? На каком основании вы решили, что SAP/R3 "своя", а CAD-система, которая используется на собственном предприятии для автоматизации работы конструкторов - "чужая"? Почему вы решили, что системы, которые на своем же предприятии используют бухгалтера или финансисты "чужие" по сравнению с SAP/R3? Насколько мне известно, SAP/R3 - это зарубежный продукт, а многие из перечисленных мной - "свои", отечественные... :) Объясните пожалуйста, что вы именуете "своим", а что "чужим".