[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Futaba] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1339708822351.jpg -(181652 B, 1075x1360) Thumbnail displayed, click image for full size.
181652 No.81687  

Сейчас любое передовое предприятие стремится максимально автоматизировать свою деятельность, повысить управляемость, информационные потоки, аналитику и т.д. Достигается это, как правило, запиливанием всё новых модулей на базе ERP - типа BI или CRM. Так за счёт интеграции на выходе мы получаем преинтересный клубок из разношерстных систем различных вендоров с вкраплениями самопилов разной свежести.
Алсо, последнее время всё активней пытаются наладит электронное взаимодействие с партнёрами (в госсекторе так это вообще пушка СМЭВ именуемая).
Причём всё это допиливается/перепиливается/обновляется. То есть, существуют некие отраслевые стандарты, но нет единой концепции чтобы хотя бы на уровне чёрных ящиков заставить всё это функционировать. Хуже того, нет даже термина определяющего информационную систему, объединяющую несколько компаний-партнёров.
Следовательно, можно ожидать, что такого рода взаимноинтегрированных компаний будет становится всё больше ибо все хотят экономить на издержках и иметь более эффективное взаимодействие. Но, из-за разношерстности этих систем сложно будет придти к единому знаменателю, что может породить нечто сродни браузерным войнам давно ушедших дней. Но, разумеется здесь всё гораздо сложнее.
Всё бы могло решиться прими вендоры единый подход (что-то сродни SOA), но тогда так уж ли они будут отличаться друг от друга? И пойдут ли они на это? Анон, а каким ты видишь будущее глобальной интеграции (странный термин но ничего интереснее сейчас на ум не приходит)?

>> No.81691  
File: 1339713314122.png -(3092 B, 200x150) Thumbnail displayed, click image for full size.
3092

>>81687
Далеко не все классы задач имеют универсальное решение, и даже если они его имеют то такое решение может быть очень далеко от оптимального. У компаний может довольно сильно различаться род деятельности и подход к ее реализации, так что решения, хорошо накладывающиеся на структуру бизнеса одной компании могут просто не подойти другой. Для производителей софта куда целесообразней оставить побольше мест для костылей нежели ломать голову над чем-то универсальным.

>> No.81712  
File: 1339785370467.jpg -(90759 B, 850x609) Thumbnail displayed, click image for full size.
90759

>>81691

>Далеко не все классы задач имеют универсальное решение, и даже если они его имеют то такое решение может быть очень далеко от оптимального.

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

>решения, хорошо накладывающиеся на структуру бизнеса одной компании могут просто не подойти другой.

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

>Для производителей софта куда целесообразней оставить побольше мест для костылей нежели ломать голову над чем-то универсальным.

Опять же нужно обеспечить не универсальное решение а взаимодействие без костылей. Например, чтобы структура реплик была стандартная и т.д.

>> No.81713  
File: 1339791236092.jpg -(22902 B, 400x396) Thumbnail displayed, click image for full size.
22902

Нам на предприятие, да и на весь производственный цикл, уже пора заводить что-то вроде годной ERP. Начальство, видимо, готовится к наплыву заказов, потому как производство расширилось и что-то отдается на в производство на стороне. Когда до этого производства - метров сто по прямой - это одно. А вот если оно в пригороде, и конструкторам надо лично удостовериться в правильности исполнения заказа - тут-то и начинается веселуха. Хоть командировки выписывай на один день.
Это что касается материального производства.

>> No.81715  
File: 1339796238571.jpg -(171842 B, 707x1000) Thumbnail displayed, click image for full size.
171842

>>81713

>на предприятие, да и на весь производственный цикл, уже пора заводить что-то вроде годной ERP
>А вот если оно в пригороде, и конструкторам надо лично удостовериться в правильности исполнения заказа - тут-то и начинается веселуха.

Как поможет ERP удостовериться в правильности выполнения заказа?

>> No.81716  
File: 1339799238725.png -(1392610 B, 1200x1400) Thumbnail displayed, click image for full size.
1392610

>>81712

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

Под разное содержимое существуют различные виды ящиков. Так и в случае ERP возможны проблемы вызванные либо недостаточной/избытой специализацией ERP либо с сильно высоким или сильно низким уровнем абстракции/сложности.

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

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

>> No.81718  

>>81715
Косвенно. По крайней мере стоило бы подумать о системе, которая спосообна эффективно все распределить, а иначе придется повышать производительность экстенсивными методами.

>> No.81732  
File: 1339933115182.jpg -(168073 B, 850x1062) Thumbnail displayed, click image for full size.
168073

>>81716

>Под разное содержимое существуют различные виды ящиков.

Что ты понимаешь под "видами ящиков"?

>Так и в случае ERP возможны проблемы вызванные либо недостаточной/избытой специализацией ERP либо с сильно высоким или сильно низким уровнем абстракции/сложности.

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

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

Э, с каких это пор call-центры используют ERP? А для станков штуки типа EAM, как правило, подрубаются в качестве отдельных модулей. ERP - это не настолько всеобъемлющее понятие чтобы мешать в него любую разновидность корпоративных информационных систем.

>> No.81734  
File: 1339934365619.jpg -(263422 B, 700x800) Thumbnail displayed, click image for full size.
263422

>>81732

> Что ты понимаешь под "видами ящиков"?

Черные ящики с различными интерфейсами.

> выделяются сервисы, а как и в каком количестве они будут использоваться - это личное дело каждого предприяти

Слишком большое количество сервисов сделает настройку ERP кошмарной, слишком малое может сделать систему малопригодной для реальной эксплуатации.

> Э, с каких это пор call-центры используют ERP?

Разве они чем-то хуже остальных?



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]