2 инженер планового отдела]..........
" Значит корпоративная информационная система ("стирающая границы") взамен локальных (выставляющих "функциональные барьеры") - это и есть способ перехода от функционального управления к процессному ? Так ?
Но, как Вы уже говорили, нужно чтобы в корпоративной информационной системе был бы "модуль" управления "бизнес-процессами" ? Так ?
Тогда - что это такое, этот "модуль" ? Как он связан с другими "модулями" (хотя, повторюсь, в корпоративной системе нет никаких модулей, а если "есть", то только в коммерческом смысле) ? "


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

Теперь по поводу корректности в обсуждении.
Здесь принято обмениваться опытом и/или знаниями. Но Вам не расскажут подробно, какой модуль управления БП должен быть в Вашей "корпоративной информационной системе", поскольку ее структуру и идеологию кроме Вас никто не знает, тем более, что у вас "в корпоративной системе нет никаких модулей".

2 проц

"Есть "БП" - изготовление гаек (для трактора)
Исполнитель - слесарь Иванов на участке 2 в цехе 5"
Нет такого БП - это несколько операций технологического процесса изготовления гайки.

А вот посоветуйте как быть с БП оплаты за поставку материальных ценностей (ТМЦ), причем будем считать, что ТМЦ уже на наших складах и вопросы проверки наличия всех документов а также соответствия качеству и количеству поставок уже проведены:
1. В службу коммерческого директора поступают счета с сопроводиловкой: "Прошу оплатить за материал поставленный (дата) по договару №***, дата (наименование, ГОСТ, типоразмер,...) количество, цена, сумма". С резолюцией типа "Разобраться" счета расходятся по исполнителям в подразделениях, отвечающих за договора по данной номенклатуре.
2. В соответствии со стандартом предприятия №*** исполнителям "разобраться" необходимо в срок, определенный стандартом. Должен запуститься счетчик и при превышении срока стартовать БП "Не решается вопрос оплаты...".
3. Исполнители проверяют договора, счета, приходные накладные, акты приемки, сертификаты качества, наличие заявки на поставку и пр. и при выявлении несоответствий инициируют старт БП "Несоответствие докементов" (ряд процессов, зависящих от типа несоответствия).
4. Если все в порядке исполнитель визирует счет и из функциональной вертикали коммерческого директора весь пакет документов уходит в службы директора по экономике. Там прежде всего снова идет полная проверка пакета плюс контролируется, а есть ли у конечного заказчика (некий цех или отдел) на его субсчете по данной статье средства и достаточно ли их для оплаты. Если нет - инициировать процесс "Что делать с принятым ТМЦ и кто будет платить и будет ли?".
5. Далее в службе директора по экономике собрали все счета за некий период (неделя, 10 дней...) и увидели, что сумма превышает планирумую на этот период. Инициировать процесс "От чего срочно отказаться или задержать оплату".
6. Если все в порядке передать документы в службу Финансоваго директора - это следующая вертикаль. Там посмотрели на содержимое счета и если денег мало инициировали процесс "Ждать пока появятся средства или вернуть ТМЦ"
7. Такой же процесс инициировали, если нет какой-то определенной валюты для оплаты.
8. Если денег хватает, передали документы в главную бухгалтерию. Если у главбуха нет более приоритетных выплат (з/п, налоги, авария,...) определенных генералом или законом, оплата пойдет, иначе будет задержка и, как и в предыдущих случаях возврат на один или несколько шагов назад.

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

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

Итак, кто может похвастать наличием в его системе хотя бы зачатков такого контроля.

Вдогонку...

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

iscrafm Guest_12345Итак, кто может похвастать наличием в его системе хотя бы зачатков такого контроля.
А премию выпишите?

Значит у Вас есть. Ну поделитесь впечатлениями, пожалуйста, как у Вас это сделано.
А премией будет повышенное внимание к Вашим продуктам, это посильнее единовременной выплаты.

iscrafm
Это индивидуальный проект. В серию такие вещи не запускаются. И еще не факт, что владельцам этой системы в конце концов не надоест излишняя подконтрольность процессов системе, а также достаточно жесткие взаимодействия между участниками. Так что нет смысла заострять на этом внимание.

Т.е. ни Вы, ни Сахават не захотели уделять проблеме внимания. Хочу только, чтобы было пончтно, я не проповедую жестких систем. Но когда идет разработка, я должен предусмотреть возможные отклонения от нормального функционирования, а срывы плановых заданий - это нормальная практика. Вы хотите, чтобы в схему было введено планирование - оно там есть. В результате планирования ОЖИДАЕМЫЕ СРЕДСТВА были рапределены, но тих не хватает. И это нормально и в плохой и в хорошей системе. Что Вы в таком случае делаете?
Так что есть смысл заострять на этом внимание.

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

Ну не надо лукавить, прошу вас обоих.

Сахават Юсифов
Все в жизни бывает, но хочется уйти от незапланированных действий (исключая тех, которые не валят ось устремлений, т.е в премлемых дозах).
Я пытаюсь учесть ВСЕ. ВСЕ настраивает клиент. Я пытаюсь синхронизировать! Решение о рассинхронизации принимает клиент.
С новым годом. Здоровья и удачи!
Люблю неспокойных!

Отмечаю 49-ый! Дай Бог и всем дожить!
Сахават.

Сахават, примите поздравления. И с Новым годом. Встретимся.

АБ
....... мы могли бы обсудить использование BPMS в такой постановке. Или в другой, но конкретной.

АБ, Вы правы, это интересный вопрос. Я уже задумываюсь о том, а не смогли бы мы своими малыми силами построить BPMS? Причем я бы пошел по пути создания продукта, интегрирующего разрозненные задачи (такова действительность, даже если система едина, она состоит из различных функциональных блоков).
Но, вот Ваши мысли: "BPMS -- это программное обеспечение, которое может состоять из различного набора компонент, но обязательными принято считать 1) визуальный редактор схем бизнес-процессов, 2) движок, который отслеживает выполнение экземпляров бизнес-процессов в соответствии с заданной схемой, 3) программные модули для мониторинга и анализа статистики выполнения бизнес-процессов." Они навевают ряд вопросов и первый: А не можем ли мы воспользоваться каким-либо готовым редактором?
Почему-то для меня именно первый пункт представляется очень трудным. Так ли это?
И еще вопрос, если думать об интеграции, то нужен механизм взаимодействия
BPMS с существующими задачами. Т.е. нужно создать инструмент, раегирующий на возникновение некоего события и передающий эти сведения движку. Сами события должны быть где-то описаны (в редакторе?) и уложены в базу с возможностью пополнения.
Всего нужно много, но путь-то верный. Надо разобраться - это вопрос/просьба.