Обсуждение бизнес-процессов управления людскими ресурсами

[Silent]

Хочу, чтобы Вы привели пример ОДНОГО Бизнес-процесса, в котором нельзя установить четкую последовательность операций.

Я же привел уже 3 примера (см. постинг от 09.10.2006, 10:05 ). Еще раз обращаю внимание на то, что я не использовал слово "нельзя". Я говорил о нецелесообразности

А я, не уважающая кибернетику молодежь, попытаюсь изобразить его не в стандарте Idef 0. И если мне это не удастся, то вы конечно окажитесь правы.

Странно. Если бы Вы уважали кибернетику, то такую задачу себе не ставили, а наоборот, эти обратные связи везде искали бы... Не существует операций без обратной связи. Это закон природы

И для моего развития, приведите, пожалуйста, пример стандартов описания бизнес-процессов, где используется "обратная связь". Это тоже для Вас не должно составить проблем. Поскольку Вы работали не только с Idef 0.

Не понял. Что значит "используется"? В любой нотации моделирования БП эту связь можно показать. Было бы желание...

[GRIG]

Не могли бы вы сказать в каких документах это регламентируется?



В целях налогообложения.
- Налоговый кодекс РФ,
- Трудовой кодекс РФ,
- Порядок ведения кассовых операций
- Постановление Правительства РФ «Об установлении норм расходов организаций на выплату суточных…»
- и т.д., целый ряд всевозможных подзаконных актов.
Все перечислить нет необходимости – Ваш бухгалтер(ия) их знает (должен знать), или узнает если возникнет необходимость.

Это всё документы, регулирующие контрольную функцию финансов, а в данном случае важнее управленческая функция (процессы желательно не только контролировать, но и управлять ими). Реализуется она во внутренних документах: учетная политика, соответствующие Приказы и Указания, возможно Положение о командировках, возможно Бюджет командировочных расходов либо аналогичная статья в бюджете верхнего уровня.

Но дело в том, что перечисленные выше документы можно написать формально, детализировав и уточнив федеральные и ведомственные нормативные акты, и по сути, также продолжить сметный подход. А можно написать, что называется «с душой» - сделать так, что сотрудники только и будут успевать пересаживаться с поезда на самолет – даже в том случае, если такие поездки наносят прямой ущерб делу, но лично им выгодны. Другая крайность, там, где интересы бизнеса могут потребовать срочного выезда сотрудника на место, он лишний раз найдет повод не сделать этого, так как ему лично эта поездка доставит одни неудобства. Т.е. весь процесс выезда сотрудников в командировки должен балансировать интересы сотрудников с целями бизнеса в целом. Именно этот процесс Вам и нужно спроектировать, исходя из собственной специфики, (либо формализовать, если устраивает существующий). Спроектировать, используя любую из имеющихся на сегодняшний день нотаций, а затем выводить некое подобие того, что Вы назвали процессограммой в виде сопроводительной документации, технологических карт выполнения того или иного процесса, или ТЗ на его автоматизацию.

Умозрительное же перечисление задач, кажущихся существенными, может привести к тому что, что вначале Вы напишите все предложения, а затем начнете из набора готовых предложений писать роман.

Напомню, что вопрос о командировках был взят для примера…

[via]

Я хочу сказать, что понятие «обратных связей» вводится в стандарте Idef 0. Поэтом говорить о них, как об универсальном элементе описания БП нельзя. Особенно для БП нижнего уровня. То есть в других стандартах описания БП понятия обратных связей не существует.

Любой БП преобразует Вход в Выход. С этим, надеюсь, Вы спорить не будете.
К любому Выходу, предъявляются Требования, которые должен обеспечить БП. С этим, надеюсь, Вы, тоже, не станете спорить.
Следовательно, любой БП, должен иметь, говоря Вашим языком, бизнес-операцию которая оценит Соответствие Выхода Требованиям и, в случае обнаружения Отклонения, активизирует бизнес-операцию устанавливающую Соответствие. Это и есть «обратная связь». IDEF0, здесь не причем, жизнь такая!
Следовательно, если диаграмма не показывает «обратную связь», то это не модель БП. Это, в лучшем случае, графическая инструкция для одного из Исполнителей ЧАСТИ БП. А в худшем – ошибка модельера.

[Алексей Владимирович]

На самом деле мы говорим не моим языком, а общепринятым. Я стараюсь опираться на какие-то стандарты для того, что бы не получилось путаницы в простой трактовке терминов. И понятие бизнес-операция не мной придумана.

Теперь по поводу вашего примера. Не совсем уловил Вашу идею. То есть не понял, что Вы имеете в виду «под обратной связью». Мне кажется весь сыр-бор из-за отсутствия «общесогласованного» определения.

Смотрите. Бизнес-процесс получения какой-то детали.

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

Если вы согласны с данной схемой, скажите, что, по-вашему, здесь является обратной связью.

[Silent]

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

[Алексей Владимирович]

Как Вы получаете деталь? Без соответвующего запроса на поставку? Без предварительно заключенного соглашения о поставке?

Я имел в виду под «получением детали» процесс обработки заготовки в результате которого получается какая-то деталь. То есть, в этом БП никаких запросов нет.

Кроме того ваши придирки абсолютно не по существу. Введите в этот БП какой-нибудь запрос и покажите мне обратную связь.

Спор состоит в следующем. Вот ваше утверждение

« Вы хотите сказать, что на нижнем уровне не может быть обратных связей? Что не может быть ситуации, когда нельзя определить, кто первый, а кто второй?»

Да я утверждаю что на нижнем уровне не может быть неопределенности кто первый кто второй. Если Вы решаете эту проблему при помощи «обратной связи», то я утверждаю о невозможности такой проблемы в принципе.

[Silent]

Я имел в виду под «получением детали» процесс обработки заготовки в результате которого получается какая-то деталь. То есть, в этом БП никаких запросов нет

При такой обработке совершается больше одной операции или одна?
Не думаю, что Вы имеете в виду последний случай
Если последовательных операций 2 шт., то от первой может быть передано что-то второй только при наличии обратной связи... По-другому не бывает...
Собственно, я это Вам уже 5-й раз пишу. Если и на этот раз моя попытка объяснить неудачна, то давайте закончим разговор к взаимному удовольствию...

Да я утверждаю что на нижнем уровне не может быть неопределенности кто первый кто второй. Если Вы решаете эту проблему при помощи «обратной связи», то я утверждаю о невозможности такой проблемы в принципе.

Я не решаю эту проблему с помощью обратной связи. У меня вообще не было такой проблемы. Это Ваша проблема - желание знать первого-второго или, др.словами, нежелание видеть обратные связи

[via]

Смотрите. Бизнес-процесс получения какой-то детали.

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

Если вы согласны с данной схемой, скажите, что, по-вашему, здесь является обратной связью.

Я не просто не согласен с данной схемой, я категорически не согласен!J
Это что же получается! У Вас три равноценных выхода – «Годная деталь», «Исправимый брак» и «Неисправимый брак». Т.е., в случае появления на выходе «Брака», Ваш БП спокойно продолжает его (Брак) производить?
На мой взгляд, еще до того, как появится ветвление между передачей Брака в процессы «Утилизация брака» или «Исправление брака», должна появиться операция «Корректировка процесса», в которой должна быть выявлена причина брака и оказано корректирующее воздействие на ту из ПРЕДШЕСТВУЮЩИХ ОПЕРАЦИЙ результатом которой стал Брак. Или даже на ПРЕДШЕСТВУЮЩИЙ БП. Это и будет обратной связью.
На вскидку, причины брака и варианты обратных связей:

• Ошибка Исполнителя по незнанию – возможна обратная связь с процессами «Подготовка кадров», «Подготовка рабочего места».
• Ошибка Исполнителя по халатности – вариантов обратной связи много, один из вариантов, с процессом «Увольнение персонала».
• Брак по вине оборудования или инструмента – обратные с вязи с процессами «Подготовка рабочего места» или «Аттестация рабочего места», или «Метрологическое обеспечение».
• Брак по вине заготовки – обратная связь с процессом поставщиком заготовок.

[Алексей Владимирович]

2 via

Мы получаем три полноценных выхода. Почему нет. Результатом БП могут быть именно они. Т.е. именно эти выходы будут входом для других БП.


По поводу расположение блока «анализа» и «корректировки», то он, на мой взгляд, возникает, когда БП «обработки детали» (который я описал) окончен. Когда есть выход, то есть деталь нормальная или бракованная. Бракованная уходит в другой процесс, где и естественно будет операция анализа причин возникновения брака. Деталь нормальная переходит на другой БП обработки, либо уходит в процесс складирования.

Совершенно с Вами согласен, что результатом брака могут быть описанные Вами причины, это будут выходЫ, которые пойдут в БП-ы «управления».
Если причина в человеческом факторе, то выход из «анализа причин брака» будет одним из входов в БП «Подготовки кадров» или «увольнения». В результате, которых исполнителя бизнес-операции поменяют или уволят.

Я еще раз хочу обратить ваше внимание, что я говорю, что обратные связи присутствуют при описании БП при помощи стандарта IDEF0. В стандартах IDEF3, DFD, ARIS, нет никаких обратных связей. Все взаимодействия между БП происходят в связях «вход-операция-выход».

[via]

Алексею Владимировичу

< Мы получаем три полноценных выхода. Почему нет. Результатом БП могут быть именно они. Т.е. именно эти выходы будут входом для других БП.

Полноценный выход только один – Годная деталь. Брак, хоть исправимый, хоть неисправимый, это, ВООБЩЕ, НЕ ВЫХОД. Это сигнал о том, что процесс работает неправильно.

< По поводу расположение блока «анализа» и «корректировки», то он, на мой взгляд, возникает, когда БП «обработки детали» (который я описал) окончен. Когда есть выход, то есть деталь нормальная или бракованная. Бракованная уходит в другой процесс, где и естественно будет операция анализа причин возникновения брака. Деталь нормальная переходит на другой БП обработки, либо уходит в процесс складирования.

Я допускаю, что иногда, для наглядности, можно нарисовать прямоугольник под названием «Управление браком». Но это не бизнес-процесс и не бизнес-операция. Это паразитический процесс, возникающий в результате сбоя в бизнес-процессах. Он не нужен бизнесу. Он ни чего не добавляет.
Процесс «Изготовление детали» не должен обеспечивать подачу Брака на вход процессу «Управление браком». Наоборот. Он всячески должен препятствовать возникновению Брака. А если мы, одним из выходов указываем, «Брак», то процесс должен называться «Изготовление деталей и Брака». Тогда да! Тогда «Брак» - полноценный выход.

< Я еще раз хочу обратить ваше внимание, что я говорю, что обратные связи присутствуют при описании БП при помощи стандарта Idef0. В стандартах Idef3, Dfd, Aris, нет никаких обратных связей. Все взаимодействия между БП происходят в связях «вход-операция-выход».

И я, еще раз хочу обратить внимание, что обратные связи объективная реальность. Легкость и наглядность их отражения в Idef0, это плюс этой нотации.
В Idef3, обратные связи менее наглядны, но от логики процесса не уйти. Приходится иногда, для удобочитаемости диаграмм, резать бизнес-процесс на кусочки, но такие диаграммы моделями БП не являются. О модели бизнес-процесса можно говорить только в отношении набора диаграмм отражающих полный Pdca цикл процесса.
Dfd-диаграммы, диаграммы потока данных. Для моделирования бизнес-процессов нотация малоприспособленная. Но думаю, что и в потоке данных есть обратные связи. Хотя, сам я, Dfd не юзаю.
Что касается Aris, то Вы меня просто пугаете! Я, всерьез собирался плотно заняться знакомством с этим продуктом. Если среди нотаций поддерживаемых Aris, нет нотаций наглядно отображающих обратные связи, то … За, что тогда такие деньги?:-)

[Алексей Владимирович]

Вы считаете, что выход из БП всегда один? или это применительно к конкретно к данному случаю.

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

Кроме того, почему Вы отвергаете возможность наличия БП, которые исправляют результаты сбоев в БП. Лично я недавно закончил описывать БП «обмен и возврат товара». Если б все было бы идеально, то его, конечно же, быть не должно. Но он есть.

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

[via]

To Алексей Владимирович

< Кроме того, почему Вы отвергаете возможность наличия БП, которые исправляют результаты сбоев в БП. Лично я недавно закончил описывать БП «обмен и возврат товара». Если б все было бы идеально, то его, конечно же, быть не должно. Но он есть.

Если Ваша компания занимается торговлей (продажей того, что производят другие), то БП «обмен и возврат товара» ДОЛЖЕН быть, потому что:
1. Он может быть инициирован законодательством (покупатель имеет право на возврат).
2. Он может быть инициирован маркетинговой политикой компании.
3. Он может быть следствием получения брака от поставщика.

Если Ваша компания продает то, что производит сама, то…
Постройте модель ваших БП с целью избавится от процесса «обмен и возврат товара». Полученную модель «Как будет» сравните с моделью «Как есть» и вы увидите, что причина обменов и возвратов отсутствие обратных связей.

[профессор элиович]

http://leadertoleader.org/leaderbook...0/drucker.html

Управление знанием в НБП-новом бизнес процессинге инновационного предпринимательства в сфере Индустрии знаний..