Моделирование процессов бизнеса и их отражения в ERP-системах

[Борисыч]

Какие нотации используете в работе? Попробуйте аргументировать выбор.
Про софт не спрашиваю - считаю, что рисовать можно и на бумаге в клеточку (с).

[komar]

EEPC, ибо в отличие от IDEF и UML понятен клиенту. Естественно, с разумным количеством значков, опять-таки чтобы не заблудиться.

[Борисыч]

Я тоже так думаю

[mazzy]

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

В IDEF3 согласен, клиенты вьезжают не сразу. В UML вообще с трудом. По крайней мере у меня, UML диаграммы так и оставались диаграммами для консультанта

Насчет EEPC... точно понимают? и сами рисуют в этой нотации?

[komar]

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

[mazzy]

а какими стоит ограничиться?
или вернее так: какие гарантировано стоит выкинуть?

[komar]

Вернее, какими стоит ограничиться. Процесс, документ, событие, процедура в системе, еще объект системы (форма, к примеру) - в первом приближении, все. Участников процесса рисовать колонками.
И не пытаться городить кучу декомпозиций, как в IDEF - наша цель не изрисовать кучу бумаги, а сформировать представление о процессе.

[Valery]

Я вот уже лет 10 в разных проектах в разных компаниях занимаюсь моделированием бизнес-процессов. Почему-то судьба у всех этих кип схем одинаковая - сразу же после издания они кладутся на полку и никогда далее не используются.

Мое глубокое убеждение - в проектах внедрения ERP-систем моделировать бизнес-процессы вообще не нужно.

Достаточно выявить функциональные требования предприятия к системе, провести GAP-FIT анализ - далее дизайн, разработка и т.д.

Зачем нужны схемы бизнес-процессов?

P.S. Я не рассматриваю случаи, когда сам клиент просит попутно с внедрением провести реинжиниринг бизнес-процессов.

[Fisher]

Занимаюсь оптимизацией и перепроектированием процессов и как следствие -
спецификацией требований к разрабатываемому на заказ ПО для ИС компании.
В своей работе использую
для описания процессов
IDEF0, IDEF3, DFD
Для спецификации требований к ПО - UML конкретно диаграммы прецендентов и активности.
Несколько слов о нотациях и языках моделирования.
IDEF0 подходит для описания системы как единого, взаимосвязанного целого и если процессы
хорошо описаны в данной нотации проблем с представлением конкретных мероприятий не происходит.
Я думаю начинать описание процессов с IDEF0 не самая лучшая идея. В моей практике эта диаграмма
развивается последовательно
на протяжении всего этапа описания.
В IDEF3 практически нереально , в отличие от IDEF0 описать процессы как связанную систему,
Но при описании отдельно взятых процессов штука незаменимая.
Отформатированная и дополненная неплохо подходит для презентации конечным потребителям.
Предпочитаю именно с неё начинать описание процессов.
DFD более всего подходит для описания ИС как единого целого.

В любом случае нотациям IDEF и DFD при описании процессов требуется расширение синтаксиса.
По поводу уровня детализации - всё определяется целью описания.

UML язык программистов и разработчиков - для них практически идеален.
Use Case, диаграмма прецендентов неплохое средство для описания фунциональных требований к ПО
Без разницы к готовому или вновь разрабатываему.
Диаграмма активности не самый лучший аналог IDEF3, при описании поведения
системы с точки зрения пользователя (готов поспорить).

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

[norwind]

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

[komar]

В том и беда, что IDEF представляет процесс "как единое целое" - как результат верхние уровни декомпозиции мало кому нужны. Те, у кого получается информация, и кто реально будет участвовать в проекте как постановщик, имеют представление только о части картины. Кроме того, простота IDEF - это и плюс, но и главный недостаток - оперируем только 4 стрелками и блоком "процесс" - при описании сложных процессов все это элементерно не поместится на листе, как следствие, теряем наглядность.
Что касается целесообразности описания как такового - описания AS IS действительно нужны только на этапе анализа, а потом идут на полку. Описания TO BE могут жить и много после, и служить основой для тех же пользовательских инструкций (естественно, ситуацию, когда идет просто рисование "для галочки", здесь не рассматриваю).

[Fisher]

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

PS Конечно, если проект небольшой и квалификация консультантов достаточно высокая, описание нецелесообразно.

[waitingforsharan]

А ARIS забыли, да? :-) Есть же функционально-ориентированное и процессно-ориентированное моделирование. Так что от цели зависит. MAP'ить процессы под систему, например, мне рекомендовалось в ARIS (это, правда, была SAP R/3). А если просто глазами посмотреть, проанализировать и т. д. - то по-моему IDEF0 вполне соответствует.

Кстати, на UML что-нибудь где-нибудь (кроме как в КРОКе) моделируют ещё? :-)

[Vadim Korepin]

Также из собствененного опыта внедрений:

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

В отличие от объектно-ориентированного подхода (UML) который понятен только ITшникам (которые естественно владеют предметом хуже спецов).

[Fisher]

По поводу UML.
Что необходимо получить от читателя диаграмм.
1 Подтверждение состава элементов даграммы.
2.Субьективное мнение (нравится не нравится).

UML в данном отношении ничем не хуже IDEF0 или DFD.
Никто не требует от читателя знания всех тонкостей построения моделей.
Кстати, полностью осознать и понять IDEF0 не менее сложно чем UML.
А Use Case пользователи читают и дают дельные замечания вообще без проблем.
Для получения продуктивной критики достаточно субьективного впечатления пользователя (критиковать модели, гораздо проще чем составлять ) .
Рекомендую показывать все спецификации, в том числе и диаграмму классов.

[Vadim Korepin]

Да не нужны классы для предметника совершенно, ему глубоко всё равно как будут построены классы - главное, чтобы бизнес-функции выполнялись в нужном ему объеме и последовательности. Как раз для этого ИДЕФ0 и нужен.

[Тимур]

Вадим. IDEF0 не предполагает последовательности процессов управления. Это так привыкли считать: сверху-слева вниз-вправо.

Цитата:

Изначально опубликовано Vadim Korepin
Да не нужны классы для предметника совершенно, ему глубоко всё равно как будут построены классы - главное, чтобы бизнес-функции выполнялись в нужном ему объеме и последовательности. Как раз для этого ИДЕФ0 и нужен.

[Vadim Korepin]

Цитата:

Изначально опубликовано Тимур
Вадим. IDEF0 не предполагает последовательности процессов управления. Это так привыкли считать: сверху-слева вниз-вправо.

В случае взаимосвязанных работ (activity), когда мы показываем на схеме потоки между ними - последовательность очевидна.

.............................+----------------+
..............................|.........1...........| ----\
.............................+----------------+......|..........+----------------+
..............................................................\-----> |...........2.........|
........................................................................+----------------+

Вот. Псевдографика спасет мир. Несмотря на отсутствие жесткого указания последовательности она очевидна. Т.е. работа 2 пользуется некой информацией работы 1.

[Тимур]

Я не возражаю. В рамках отдельных декомпозиций последовательность можно проследить, но не вцелом.

[spy]

OFF: В свое время наткнулся на такой забавный пример.

На диаграмме IDEF может быть показано как выглядит "типовое готовое рабочее место".
[FIG1]