Бизнес-процессы

[Сергей А. Степанов]

asergeey, Вы какой либо нотации придерживались при построении или эта «картина» результат исключительно собственной методики описания? :-)

[Михайло]

Управленческие бизнес-процессы по PMBoK от 2008 (пока еще не совсем закончил модель, но посмотреть можно):

[Петров Дмитрий]

Спасибо всем большое. Мало у меня времени что бы успевать все читать и при этом рисовать модели Но я прочел все то, что вы написали. Сделал наброски. И вот что получилось. Прошу прокомментировать. Спасибо.

Это не IDEF0, и не IDEF3 Собственно, а чего Вы добиваетесь? С какой-то конкретной целью строите или так, просто потренироваться? Если неохота книжки читать - скачайте специализированные программные продукты и посмотрите там демонстрационные базы данных процессов виртуальных предприятий. Вот вам на выбор:
Fox Manager (Нотация Basic FlowChart) - http://www.fox-manager.com.ua/
Business Studio (Нотации IDEF0 + Cross Functional Flowchart + EPC) - http://www.businessstudio.ru/

[asergeey]

Уважаемые товарищи. Для чего я это все делаю. Поясню. Главная цель моих стараний- это улучшить процессы в моем отделе. Потому что я вижу что многое можно изменить. На словах это трудно объяснить босу. По этому я решил, что мне нужно узнать каким образом это можно сделать. Мне посоветовали одни из Вас воспользоваться методологией описания и стандартов IDEF0. Сейчас, я хочу понять, что и куда должно рисоваться. Задачу оптимизации процесса я у себя в голове решил . Но для босса нужны более убедительные материалы. Вот когда я ему покажу схему и все подробно расскажу что за чем идет, то он меня поймет (я надеюсь) ))). Вот мои цели. за одно мне просто интересно для себя все упорядочивать и делать это грамотно. Вот и читаю.

[Сергей А. Степанов]

Уважаемые товарищи. Для чего я это все делаю. Поясню. Главная цель моих стараний- это улучшить процессы в моем отделе. Потому что я вижу что многое можно изменить. На словах это трудно объяснить босу. По этому я решил, что мне нужно узнать каким образом это можно сделать. Мне посоветовали одни из Вас воспользоваться методологией описания и стандартов IDEF0. Сейчас, я хочу понять, что и куда должно рисоваться. Задачу оптимизации процесса я у себя в голове решил . Но для босса нужны более убедительные материалы. Вот когда я ему покажу схему и все подробно расскажу что за чем идет, то он меня поймет (я надеюсь) ))). Вот мои цели. за одно мне просто интересно для себя все упорядочивать и делать это грамотно. Вот и читаю.

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

Итого, материалы для изучения IDEF вам предложены, инструменты для рисования тоже. Но прилежности в изучении что-то не видать, ваша последняя схема IDEF0 не соответствует, другим известным мне нотациям тоже. Отсюда не очевидно, какой смысл вы в неё вложили, а значит и рецензировать бессмысленно. Если у вас иное мнение — аргументируйте, допускать ошибки не зазорно — получите и конструктивное обсуждение. Но большая ошибка — полагать, что вы вправе рассчитывать на публичные лекции где бы то ни было, на том одном лишь основании, что у вас не достаёт времени на самостоятельное прочтение / изучение рекомендованных материалов. Так ведь и здешние комментарии / рекомендации боюсь не асилите.

[asergeey]

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

[Михайло]

Трудно мне понять что "Управление" - это БОСС, а "Выход" - это стул.

Что тут непонятного? Если воздействие со стороны босса изменится, то стул может стать другим. Запомните: в бизнес-моделях речь не идет только о настоящем времени, все входы и выходы меняются во времени. Модель живая - босс может смениться, либо его стиль управления может смениться - все это повлечет изменения в экземплярах стульев. Все изменения произойдут согласно модели, если она верно построена и в нее не были внесены изменения.

[Bend]

Пока прошу прокомментировать следующий рисунок.

ИМНО: может входом должен быть не товар, а его спецификация, характеристика, как это называется там...

[asergeey]

Что тут непонятного? Если воздействие со стороны босса изменится, то стул может стать другим. Запомните: в бизнес-моделях речь не идет только о настоящем времени, все входы и выходы меняются во времени. Модель живая - босс может смениться, либо его стиль управления может смениться - все это повлечет изменения в экземплярах стульев. Все изменения произойдут согласно модели, если она верно построена и в нее не были внесены изменения.

То что вы написали, для меня как на китайском языке . Что то я запутался. На сколько я понимаю мне сейчас нужно просто нарисовать схему процесса, что за чем выполняется (действия людей для получения конечного результата). Вместо того что бы писать это на бумаге типа:
№1. менеджер сделал то-то
№2. после того как менеджер сделал то-то, кто-то другой должен сделать что-то... и т.д.
Мне надо это прорисовать и подкрепить описанием. Стандарты IDEF0 или IDEF3 для этого подходят или нет??? Я что-то понять не могу... ХЭЛП!!!!!

[Bend]

Подходят, конечно. Для начала IDEF0.
Михайло говорит о том, что вся построенная модель бизнес-процессов - очень гибкая и она действительна до тех пор, пока босс (управление, верхняя стрелка) не захочет что-нибудь изменить, поменять регламенты (тоже может быть управлением для других процессов), что может оказать влияние на выход процесса. Например, на входе полено, процесс - производство стула, поменялось управление процессом (регламент), и выходом может быть уже не стул, а полуфабрикат, или вообще стол, кресло, и так далее...
Но так как все связано, новый выход окажет влияние на другие процессы.
Описание бизнес-процессов - это как описание текущей работы компании. Если в процессе описания БП что-то изменилось, нужно смотреть что и менять схему, если все по прежнему - то вы получаете рабочую модель.
ИМНО все

[Евгений_Кс]

Я что-то понять не могу... ХЭЛП!!!!!

Написал Вам в личку.

[asergeey]

Написал Вам в личку.

Ответил Вам в личку Но н знаю, как то тут сайт работает странно ))

[Сергей А. Степанов]

asergeey, в целом последняя схема логике idef0 не противоречит, из этого следует что с такими понятиями как «управление», «вход», «выход» и т.д. Вы всё таки разобрались, а значит не всё так плохо :-)

Стандарты IDEF0 или IDEF3 для этого подходят или нет??? Я что-то понять не могу... ХЭЛП!!!!!

Подходят ли для решения конкретной задачи стандарты серии idef решать только Вам. Протестировав в данных нотациях пару своих примеров, Вы получите представление о имеющихся ограничениях; а сопоставив результаты моделирования со своими «хотелками» сможете сформулировать свой собственный список «что понравилось, а что — нет». И вот уже дальше, на основании этого списка можете принимать решение о принципиальной применимости / не применимости idef в Вашем случае, и при необходимости продолжить поиски «Грааля». Сейчас же просто не ясно, что вас не устраивает в idef и сложно предлагать вам что-то иное.

Коротко об отдельных нотациях семейства IDEF:
- IDEF0 — позволяет грубо говоря изобразить «концепт» процесса с требуемой степенью декомпозиции;
- IDEF1/1x — предоставляет возможность акцентировать внимание на информационной системе;
- IDEF3 — даёт возможность сосредоточиться на условных ветвлениях потока работ
В дополнении рекомендую взглянуть на DFD Гейна-Сарсона — красиво «укладывает» потоки информации в общий формат диаграмм IDEF.

Как правило в большинстве случаев этого более чем достаточною. Диаграммы позволяют быстро схематично выстроить связи, текстовые процессоры — подготовить описание / регламенты к ним :-) Если желаете более продвинутых и современных инструментов, welcome — UML, BPML/BPMN…

[asergeey]

Так товарищи. Вот есть первый шаг. Прошу коментов. Сейчас работаю над детальной диаграммой.

[Михайло]

Так товарищи. Вот есть первый шаг. Прошу коментов.

Почти все правильно. Возможно ты забыл в качестве инструментов (стрелка снизу) пристегнуть весы, линейку и т.п. Раз товар пришел его нужно чем-то измерять... Это детали, на которые можно не обращать внимание, так как они само собой разумеются. Лично я даже рекомендую пока сконцентрироваться на товарной цепочке (товар, документ,событие, а стрелки снизу и сверху не рисовать).

[Евгений_Кс]

Так товарищи. Вот есть первый шаг. Прошу коментов. Сейчас работаю над детальной диаграммой.

У меня небольшой опыт, но выскажусь.
1. Слева я бы сделал две стрелки "Товар" и "Спецификация", чтобы исключить всякие "и".
2. Сверху "Должностная инструкция" - не хорошо. ДИ определяет перечень обязанностей, но не последовательность действий по конкретной обязанности. Сверху должна быть рабочая инструкция, Регламент, Порядок заполнения базы данных (пришел новый человек - взял в руки инструкцию и начал заполнять)
3. Всякие "и т. д." должны быть исключены (см. в прямоугольнике). Ведь перечень заполняемых полей в БД однозначно определен.
4. В прямоугольнике - не "вносить информацию", а "внесение информации".

[alex9994]

У меня небольшой опыт, но выскажусь.
1. Слева я бы сделал две стрелки "Товар" и "Спецификация", чтобы исключить всякие "и".

ИМХО 1 Если товар вошел, то он должен и как-то выйти....
товар не преобразуется в информацию в базе данных...
ИМХО 2 Не уверен, что товар участвует в этом процессе. Данные берутся с документов (спецификация, других ностелей информации), но с самим товаром ни каких действий при "вносить информацию" не производится.
Иначе говоря, левая стрека "товар" в данном примере не нужна...

[asergeey]

ИМХО 1 Если товар вошел, то он должен и как-то выйти....
товар не преобразуется в информацию в базе данных...
ИМХО 2 Не уверен, что товар участвует в этом процессе. Данные берутся с документов (спецификация, других носителей информации), но с самим товаром ни каких действий при "вносить информацию" не производится.
Иначе говоря, левая стрелка "товар" в данном примере не нужна...

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

[Евгений_Кс]

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

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

[alex9994]

"Если товар вошел, то он должен и как-то выйти". Не согласен. Это же не схема движения материальных продуктов, а описание процессов. На входе процесса может быть материальный объект - а на выходе - его описание.

Тогда и на выходе должен быть уже описанный объект... только процесс будет другой по содержанию, описание и внесение описания в базу...
вход должен преобразоваться в выход
если процесс только во внесении данных в базу, то сам объект для этого не нужен...
а иначе материальный объект преобразуется в информацию на носителе...

P.S. Само моделирование идет как-то странно... не сверху вниз, а откуда-то сбоку...

[Евгений_Кс]

если процесс только во внесении данных в базу, то сам объект для этого не нужен...

Да, конечно, поэтому я и предложил ввести еще процесс, если нет к объекту спецификации.

иначе материальный объект преобразуется в информацию на носителе...

Да, конечно, и в этом ничего страшного. Вы пришли в студию сфотографироваться. На входе процесса - Вы, на выходе процесса - Ваша фотография.
Ну, и на выходе из студии - Вы, конечно.

Само моделирование идет как-то странно... не сверху вниз, а откуда-то сбоку...

Почему странно? Таков стандарт IDEF0. Слева - входы, справа - выходы. Цепочка подпроцессов в целом сдвигается вправо вниз.

[alex9994]

Вы пришли в студию сфотографироваться. На входе процесса - Вы, на выходе процесса - Ваша фотография.
Ну, и на выходе из студии - Вы, конечно.

вот именно а не перевод меня в фотографиююю

Почему странно? Таков стандарт IDEF0. Слева - входы, справа - выходы. Цепочка подпроцессов в целом сдвигается вправо вниз.

Евгений

Странно другое, не то что входы слева и выходы справа, а то что моделирование процессов откуда-то с произвольного места процессного ландшафта...

[asergeey]

4. В прямоугольнике - не "вносить информацию", а "внесение информации".

Спасибо всем за активное участие. Но осмелюсь Вам отрицать Евгений_Кс вот что я нашел в книге
Имена и метки.
Как указывалось, имена функций – глаголы или глагольные обороты. Примеры таких имен:
производить детали, планировать ресурсы, наблюдать за выполнением, проектировать систему, проверять деталь и т.д.
А так же хочу прояснить всем, почему может казаться что процесс из ниоткуда появился. Потому, что я хочу внедрить этот процесс, он совершенно новый для нашей компании. То есть я рисую со средины. Так же прилагаю новое свое творение Прошу посмотреть. Думаю у меня уже чуть лучше получается чем раньше . Но опять же, это детальная диаграмма родительской диаграммы. Родительской диаграммы пока нет

[eliferov]

Спасибо всем за активное участие. Но осмелюсь Вам отрицать Евгений_Кс вот что я нашел в книге
Имена и метки.
Как указывалось, имена функций – глаголы или глагольные обороты. Примеры таких имен:
производить детали, планировать ресурсы, наблюдать за выполнением, проектировать систему, проверять деталь и т.д.
А так же хочу прояснить всем, почему может казаться что процесс из ниоткуда появился. Потому, что я хочу внедрить этот процесс, он совершенно новый для нашей компании. То есть я рисую со средины. Так же прилагаю новое свое творение Прошу посмотреть. Думаю у меня уже чуть лучше получается чем раньше . Но опять же, это детальная диаграмма родительской диаграммы. Родительской диаграммы пока нет

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

[Михайло]

Я бы вместо объекта "товар" на вход подал бы объект "данные с ярлыка/упаковки товара".
А с выхода "товар" я бы убрал - это концептуальная ошибка! Ибо "товар" является выходом производственного процесса завода-изготовителя. Один и тот же объект не может быть выходом разных процессов.
И потом: "повисшие в воздухе" стрелки можно убивать: т.к. такие объекты не идут на вход какого-либо другого процесса, то значит их нет смысла обозначать.
Если товар на выходе все-таки нужен, то его необходимо назвать по-другому, например, "товар, прошедший регистрацию в базе данных".

И это... Вертикальный текст пиши снизу вверх (чтобы голову наклонять влево, а не вправо).

[Евгений_Кс]

Уже лучше!
Вас настойчиво толкали в наиболее употребительные нотации (IDEF0,IDEF3 и т.д) исключительно для того, чтобы разговаривать о модели на одном языке.
С уважением Виталий.

Сергей, Вам крупно повезло: Общее видение контролирует гуру процессного подхода Виталий Елиферов, а с отдельными стрелочками и прямоугольничками с Вами работают специалисты среднего уровня.
Пользуйтесь!
Советую детально разобраться с последним постом Виталия и, если что неясно, задать вопросы.

[А.Б.]

Меня опять терзают смутные сомнения. А может быть вместо того, чтобы заниматься ЭТОЙ ерундой, руководству компании лучше пустить ЭТИ деньги на зарплату:
- маркетологов, чтобы закупали не то что валяется на полках, а то что нужно покупателям;
- внутреннего контроля, чтобы чеки не стоили в 2 раза больше чем на самом деле купил покупатель и чтобы этикетки со сроком годности на колбасе не переклеивали пока она не позеленеет;
- мерчендайзеров, чтобы то что нужно покупателю не лежало на высоте 3 метра, а то что не нужно не загромождало проходы.

Остаюсь при необычном (для авторов данной ветки) мнении, что моделировать и автоматизировать нужно только те процессы для которых от этого будет хоть какой-то эффект. Ну и: учиться надо в институте, а на рабочем месте надо работать.

[eliferov]

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

Я о том же писал....

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

Ну и: учиться недо в институте, а на рабочем месте надо работать.

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

[asergeey]

Меня опять терзают смутные сомнения. А может быть вместо того, чтобы заниматься ЭТОЙ ерундой, руководству компании лучше пустить ЭТИ деньги на зарплату:
- маркетологов, чтобы закупали не то что валяется на полках, а то что нужно покупателям;
- внутреннего контроля, чтобы чеки не стоили в 2 раза больше чем на самом деле купил покупатель и чтобы этикетки со сроком годности на колбасе не переклеивали пока она не позеленеет;
- мерчендайзеров, чтобы то что нужно покупателю не лежало на высоте 3 метра, а то что не нужно не загромождало проходы.
Остаюсь при необычном (для авторов данной ветки) мнении, что моделировать и автоматизировать нужно только те процессы для которых от этого будет хоть какой-то эффект. Ну и: учиться надо в институте, а на рабочем месте надо работать.

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

[А.Б.]

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