Валентин КИзменение розничной цены - это событие организационное, а не программное, т.е. назначить новую цену может директрор либо директор по продажам, но не программист... и отчеты для этого никакие не нужны !!! и для того, чтобы узнать цены у конкурентов программисты тоже не нужны !!! а нужны менеджеры.
Для того, чтобы в системе внести изменение цены программисты не нужны !!! нужен оператор, который изменит цену на товар по подписанному бумажному распоряжению на изменение цен...Ндаа... Достучаться не просто... :)
Речь идет не просто об изменении цены! Чисто механическое изменение цены в меньшую сторону ограничено СБЕБСТОИМОСТЬЮ ! После того, как цена пересекает этот порог, производство становится убыточным. И даже прибыльное производство, но МАЛО прибыльное обречено на вымирание, поскольку в критический момент оно не сможет изыскать необходимые ресурсы чтобы кардинально изменить свою эффективность, когда предприятие начнут обходить конкуренты - именно за счет этой массы прибыли и образуются источники финансирования инноваций.

Так вот, речь идет не просто об уменьшении цены , речь идет об уменьшении себестоимости . Чувствуете разницу? И опять-таки не только об уменьшении себестоимости, но и одновременном улучшении качества . Можно эти вопросы решить, не изменяя бизнес-процессы, одной лишь бумажкой, переданной оператору?

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

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

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

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

Валентин КДалше действия:
1) Попытки изменить состав закупки товара на более дешевый ассортимент
2) Попытка уменьшить постоянные издержки
3) Попытка уменьшить переменные издержки, в основном организационными методами и реструктуризацией объемов закупки и хранения товара.
4) Поиск узких и широких мест в организиционной структуре и оптимизация штатов, перераспределение обязанностей и пр...Все эти "попытки изменить" - это и есть изменение бизнес-процессов. Допустим, раньше мы использовали склад, на котором складывали запасы произведенной продукции и полуфабрикаты. В некоей используемой на предприятии автоматизированной системе были настроены соответствующие процедуры передачи продукции и полуфабрикатов из цеха на склад. Теперь мы пораскинули мозгами, пригляделись к опытку японцев, решили убрать склад ко всем чертям, кладовщиков уволить, бывшее помещение склада переоборудовать под производственное, и торговать "с колес". Это позволит снизить издержки, связанные с хранением, и не только... Высвободятся оборотные активы, замороженные в постоянно храниимых на складе материальных ценностях. То есть, финансовое положение улучшится. Но для того, чтобы перейти на торговлю "с колес" мы должны обеспечить высокую оперативность, моментальную реакцию на проиходящие события, пересмотреть сови отношения с поставщиками и работать только с теми, кто также готов работать оперативно, поставлять качественный товар и при этом не срывать сроки поставки. Мы должны убрать или упростить у себя 30 процедур согласований, сократить производственный цикл в 3 раза.
Посидели, покумекали, пришли к выводу - начинаем работать по новой схеме! И... пошли к программисту .
- Дорогой программист, переделай пожалуйста программу так, чтобы вот эти операции не были связаны со складом, теперь они должны завязаться на транспортный отдел. Убери вот эти согласования. Алгоритм вот этих согласований нужно изменить - тут сократить таймауты, здесь изменить маршруты, здесь использовать другие новые формы (вот образцы). На каждую фазу выполнения каждой операции под каждый заказ необходимо поставить логический "светофор", который бы загорался желтым или красным, если намечаются какие-либо проблемы, светофоры необходимо вывести вот к этим руководителям... бала-бала-бала-бала.... (для того, чтобы не загромождать пост, все последующие два квадратных километра монолога пропущены :) ). ... бала-бала-бала-бала... Сколько уйдет времени, чтобы перенастроить используемое программное обеспечение?
- Приходите года через два.
- Как!!!??? Через два года мы уже разоримся!
- Ну тогда через полтора, но с вас ящик пива...

Валентин КА где тут роль программистов?Смогли рассмотреть такой большой тормоз в приведенной выше ситуации? Вот роль этого тормоза он и выполняет. :)

Валентин КИ BPMS где должна быть и что она даст в каждом из перечисленных пунктов?Садится бизнес-аналитик, и за день-два рисует схемы новых бизнес-процессов в BPMS, еще часа два расходует программист, чтобы сделать привязку интерфейсов и адаптеров. Не прочувствовали разницу?

P.S. Пример несколько скандальный и спорный, поскольку он в большей степени относится к реинжинирингу, нежели к пошаговому постепенному улучшению. Но зато наглядно демонстрирующий, для чего нужна BPMS.

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

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

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

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

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

iscrafm:)Что, прикольно? :) Разумеется, я несколько утрирую (и этого не скрываю). Бизнес-аналитик лоб расшибет, пока продумает более-менее непротиворечивый алгоритм работы. И, разумеется, на это уйдет не два дня. Я сам участвовал в подобных "генерациях новых схем", и знаком с этими вещами двольно близко. Обычно кардинально новые схемы работы генерятся на множестве совещаний, утверждаются на самом верхнем уровне и только после многократного почесывания во множестве затылков запускаются в работу, после чего оказывается, что забыли предусмотреть примерно 2/3 всего того, что нужно было предусмотреть... :) Я же предупреждал - пример скандальный. Реинжиниринг - это вообще отдельный разговор.

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

Когда работа будет выполнена и бизнес-процесс запущен, выяснится, что очень многое в нем забыли предусмотреть. В процессе выявления всякого рода возникающих на практике проблем, бизнес-аналитик постоянно модифицирует схему бизнес-процесса прямо "на ходу", когда она уже выполняется, когда по ней уже запущено великое множество операций, и остановить которые - смерти подобно. Далее подгонка бизнес-процесса, его изменение, оптимизация производится ХРОНИЧЕСКИ . Потому что "нет предела совершенству" и потому что внешняя среда также не остается неизменной - под нее нужно успевать подстраиваться. Если у вас запущен 1С с навороченной самописной конфигурацией, то любые изменения в нем потребуют привлечения 1С-программиста, 1С-программисту придется вникать во все тонкости всех процедур, в нюансы, в то, что "еще не произошло, но может произойти"... В BPMS программисту это ничего не нужно и от него в 100 раз меньше требуется. Ему нужно лишь прописать адрес почтового ящика, параметры интерфейса, схемы преобразования форматов. Всё.