#проектирование_процессов — Public Fediverse posts

Проектирование бизнес-процессов в ERP-проектах

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте. Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3]. Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

https://habr.com/ru/articles/983360/

#графическое_моделирование #as_is #to_be #как_есть #как_будет #bpm_cbok #проектирование_процессов #оргструктура #bpmn_20 #bpmnдиаграмма

Проектирование бизнес-процессов в ERP-проектах

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте. Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3]. Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

https://habr.com/ru/articles/983360/

#графическое_моделирование #as_is #to_be #как_есть #как_будет #bpm_cbok #проектирование_процессов #оргструктура #bpmn_20 #bpmnдиаграмма

Проектирование бизнес-процессов в ERP-проектах

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте. Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3]. Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

https://habr.com/ru/articles/983360/

#графическое_моделирование #as_is #to_be #как_есть #как_будет #bpm_cbok #проектирование_процессов #оргструктура #bpmn_20 #bpmnдиаграмма

Проектирование бизнес-процессов в ERP-проектах

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте. Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3]. Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

https://habr.com/ru/articles/983360/

#графическое_моделирование #as_is #to_be #как_есть #как_будет #bpm_cbok #проектирование_процессов #оргструктура #bpmn_20 #bpmnдиаграмма

Искусственный интеллект в консалтинге: почему методология важнее технологии

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

https://habr.com/ru/companies/bft/articles/958388/

#искусственный_интеллект #консалтинг #автоматизация_бизнеспроцессов #проектирование_процессов #анализ_процессов #оптимизация_процессов #зрелость_процессов

Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает

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

https://habr.com/ru/companies/kaiten/articles/925044/

#диаграмма #kaiten #бизнеспроцессы #проектирование_процессов #dfd #диаграмма_потока_данных

Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает

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

https://habr.com/ru/companies/kaiten/articles/925044/

#диаграмма #kaiten #бизнеспроцессы #проектирование_процессов #dfd #диаграмма_потока_данных

Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает

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

https://habr.com/ru/companies/kaiten/articles/925044/

#диаграмма #kaiten #бизнеспроцессы #проектирование_процессов #dfd #диаграмма_потока_данных

Диаграмма потоков данных (DFD) для чайников: что это такое, как сделать и какой бывает

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

https://habr.com/ru/companies/kaiten/articles/925044/

#диаграмма #kaiten #бизнеспроцессы #проектирование_процессов #dfd #диаграмма_потока_данных