Интеграция приложений: методы взаимодействия, топология, инструменты
Способы связывания приложений. Интеграция данных.
2.2. Способы интеграции приложений
Вход для зарегистрированных пользователей. Вопросы интеграции приложений предприятия активно обсуждаются сегодня компьютерным сообществом. Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов. Обычны ситуации, когда в рамках одного бизнес-процесса задействованы разные информационные системы. Многие информационные системы изначально ориентированы на получение информации из других приложений и баз данных например, системы формирования сводной и корпоративной отчетности, системы управления и мониторинга. В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказываются в выигрышном положении с точки зрения обоснования перед людьми, принимающими решение о финансировании проектов: Успешная интеграция корпоративных систем позволяет достичь и дополнительных целей — обеспечить автоматизированный контроль прохождения основных бизнес-процессов на предприятии, информационную безопасность при реализации бизнес-процессов и т. Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния. Не надо забывать, что основная цель интеграционных проектов — снижение издержек, равно как и предпосылки к проектам лежат в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия. Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщениями. В этом списке нет прямого обмена данными между базами данных приложений: С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку например, при загрузке накладных пересчитывать товарные остатки. Прямой обмен данными, который обычно выполняется средствами класса ETL extract, transfer, load или самодельными утилитами, обычно такой возможности не предоставляет. Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Данный подход концептуально очень прост — несколько информационных систем или приложений используют одну базу данных. Главный его недостаток — связь между интегрированными приложениями настолько тесная, что иногда невозможно заметить границу между ними обычно так интегрируются продукты одного производителя. Примером такого подхода могут служить большинство ERP-систем, где различные модули системы используют одну базу. С этим борются, используя механизмы серверов баз данных представления данных, промежуточные таблицы и т. Стандарты на удаленный вызов процедур возникли два десятка лет назад, позволяя программному коду, который выполняется на одном компьютере, вызывать код на другом. Стандарты появлялись, развивались и угасали: RPC, CORBA, DCOM, RMI… последним в этом ряду стал протокол SOAP, основа современных Web-сервисов. Собственно в подходе к интеграции с использованием удаленных вызовов за эти годы ничего принципиально не изменилось — если приложению А что-то нужно от приложения Б, то А одним из перечисленных способов вызывает функцию приложения Б. Основной недостаток удаленного вызова — требование работоспособности всех задействованных приложений в момент взаимодействия. Представьте себе систему ведения справочников, изменения из которой каждую ночь распространяются в десятки корпоративных систем. Вероятность того, что, скажем, в два часа ночи все корпоративные системы находятся в состоянии полной боеготовности, невелика. Опыт показывает, что подход, основанный на удаленном вызове, приемлем только в тех случаях, когда взаимодействие приложений инициируется пользователем, который сам контролирует результат. Для автоматического взаимодействия без участия человека данный подход практически неприменим. В этом нет ничего удивительного: Это, пожалуй, единственный из перечисленных подходов, который создавался специально для интеграции информационных систем. Идея концептуально проста и напоминает работу электронной почты. Когда приложению А необходимо вызвать какое-то действие в приложении Б, оно формирует соответствующее сообщение с данными и инструкциями и отправляет его посредством системы доставки сообщений. Сообщение гарантированно доставляется благодаря механизму очередей сообщений, которые снимают с взаимодействующих систем заботу о надежности сети передачи данных, работоспособности взаимодействующих систем в конкретные моменты времени и т. Недостаток данного подхода — высокая цена. Система гарантированной доставки на основе очередей сообщений обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue MSMQ , компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные например, ActiveMQ , которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т. Существует два подхода к организации маршрутов взаимодействия интегрируемых системы. Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами. При данном подходе интегрированные системы взаимодействуют напрямую. Преимущества подхода — простота, прозрачность и отсутствие необходимости в дополнительном программном обеспечении. Однако, есть и недостатки. При изменении одного из приложений если оно повлекло за собой изменение интерфейса взаимодействия данного приложения приходится модифицировать или как минимум перенастраивать все интегрированные с ним системы. Во-вторых, в информационной системе предприятия появляется слишком много связей, каждую из которых нужно контролировать и поддерживать в работоспособном состоянии. Если взаимодействующих приложений много, стоимость сопровождения интегрированной таким образом информационной системы предприятия становится неприемлемо высокой. Это происходит, как правило, в тех случаях, когда при взаимодействии конкретных приложений необходимо передавать большие объемы данных или обеспечивать нормированное время взаимодействия, а также если эксплуатируемые на предприятии приложения имеют встроенные средства взаимодействия это часто случается при внедрении нескольких систем от одного поставщика, а также если при разработке заказных программных систем или внедрении новых к ним изначально предъявляется требование по взаимодействию с уже имеющимися системами. Эти недостатки призвана решить архитектура взаимодействия, в которой все приложения непосредственно соединены только с центральным узлом, решающим следующие задачи:. Благодаря введению промежуточного звена, уменьшается число связей между приложениями, устраняются прямые связи, а система интеграции становится более гибкой и дешевой в эксплуатации. Если меняется одно из интегрированных приложений, то — при условии правильно спроектированной системы интеграции — нужно будет модифицировать только одну связь, между данным приложением и хабом. Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Перед выбором программных средств интеграции необходимо четко определить все системы, нуждающиеся в координации или в обмене данными с другими системами; документировать все возможные протоколы взаимодействия, требования по объему данных, расписанию обмена и т. Ключевым моментом также является необходимость участия человека в процессе взаимодействия информационных систем. Часто это диктует выбор решений, не имеющих, на первый взгляд, отношения к интеграции. Собрав и документировав информацию о будущей картине взаимодействия приложений, необходимо отобрать минимальный набор приложений, дающих все варианты методов взаимодействия, протоколов и т. Возможны разные требования по объему и видам передаваемых данных, по стилям интеграции и так далее — нужно сформировать минимальную по объему репрезентативную выборку, и на ее основе выбирать комплект продуктов для интеграции и запускать пилотный проект. До завершения пилотного проекта нет необходимости приобретать интеграционное программное обеспечение — всегда есть возможность получить временные лицензии и все проверить. При этом партнеры поставщиков таких решений, как правило, решают вопросы проверки оперативнее самих поставщиков, и, самое главное, могут обеспечить техническую поддержку еще до покупки лицензий. Сегодня технология Web-сервисов позиционируется как удобное средство интеграции приложений, поскольку позволяет реализовывать, развертывать, и обеспечить простое межплатформное взаимодействие. К сожалению, наш опыт говорит о практической неприменимости современных технологий Web-сервисов для интеграции приложений как общего подхода. Действительно, пока Web-сервисы оказываются непригодны для обработки больших объемов информации; в них отсутствуют средства поддержки транзакций; взаимодействующие системы должны находиться в работоспособном состоянии на момент взаимодействия. Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают. Далее представьте, что в процессе взаимодействия множества информационных систем необходимо провести согласованные изменения в некоторых из них, то есть выполнить логическую транзакцию, затрагивающую несколько систем. Если для интеграции используются Web-сервисы, то такой возможности нет: Скажем, если из трех участвующих в логической транзакции приложений два смогли выполнить какую-то операцию, а одно — нет, то в двух системах нужно выполнить действия отката, отменяющие результат успешно выполненных операций. В теории подход хорош, но, во-первых, никто не гарантирует успех компенсационной операции, а во-вторых, некоторые системы например, финансовые не допускают удаления данных, внесенных в базу. Предварительный стандарт WS-Transactions, призванный решить данную проблему, существует, но отсутствуют его полноценные реализации. Так, корпорация IBM заявила о поддержке этого стандарта в своих интеграционных продуктах, основанных на WebSphere Application Server, но с массой ограничений; самое главное из которых — все взаимодействующие Web-сервисы должны работать под управлением WebSphere Application Server. Аналогичная ситуация и у Microsoft в. Но самое печальное в ситуации с Web-сервисами — не отсутствие реализаций стандартов, сдерживающих их применение для интеграции приложений. Плохо то, что после реализации всех необходимых стандартов Web-сервисы рискуют потерять то, благодаря чему они стали столь популярны, — простоту создания, развертывания, поддержки. Поддержка WS-Transactions, WS-Attachments и других стандартов, расширяющих возможности Web-сервисов, может резко усложнить их создание, отладку и развертывание. Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия Enterprise Service Bus, ESB. Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции. Что же получилось в действительности? Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Означает ли это конец еще одной красивой сказки? Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов. Вокруг архитектуры, ориентированной на сервисы Service-Oriented Architecture, SOA , также очень много маркетинговой шумихи. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т. При этом производителям, скорее всего, потребуется переписать свои системы. Так или иначе, следующие несколько лет покажут, насколько жизнеспособна концепция SOA. Алексей Добровольский ADobrovolsky croc. Для реализации своих идей стартапы сегодня уже не нуждаются в непомерных средствах, однако им требуются инструменты, позволяющие быстро вывести продукт на рынок, чтобы продемонстрировать его возможности инвесторам и сразу получать прибыль. В этом им могут помочь хорошо Большинство компаний пока топчутся у подножия вершин интеграции, и хотя головы кружат облака, добраться до них можно только через интеграцию сервисов. Однако, не научившись интегрировать приложения и данные, сделать это невозможно. Текущее состояние ИТ-ландшафта компаний характеризуется как гибридное — бизнес-процессы поддерживаются конгломератом локальных, мобильных и облачных приложений, что следует учитывать при их интеграции. Ключевыми возможностями платформы такой интеграции являются Корпоративные системы стремительно эволюционируют — монолитные приложения сменяются распределенными, основанными на сервисной архитектуре, обеспечивающей возможность быстрой перестройки бизнес-процессов. Как адаптировать унаследованные системы к требованиям нового Computerworld LAN Директор ИС Открытые системы Windows IT Pro Мир ПК DGL. Тема номера Текущий номер Current Issue Архив Об издании About Issue. Интеграция Интеграция приложений Application integration. Практика перехода на Windows Купить номер с этой статьей в PDF. Инструмент для стартапа Для реализации своих идей стартапы сегодня уже не нуждаются в непомерных средствах, однако им требуются инструменты, позволяющие быстро вывести продукт на рынок, чтобы продемонстрировать его возможности инвесторам и сразу получать прибыль. Как покорить интеграционные вершины? Гибридная интеграция Текущее состояние ИТ-ландшафта компаний характеризуется как гибридное — бизнес-процессы поддерживаются конгломератом локальных, мобильных и облачных приложений, что следует учитывать при их интеграции. Сервисы, архитектура и унаследованные системы Корпоративные системы стремительно эволюционируют — монолитные приложения сменяются распределенными, основанными на сервисной архитектуре, обеспечивающей возможность быстрой перестройки бизнес-процессов. Разное Платформы Академия ОС Современные архитектуры Тема номера Безопасность Руководителю проекта Менеджмент ИТ Alt. Об издательстве Об издании Обратная связь Как нас найти Контакты О републикации Теги Архив изданий Политика обработки персональных данных. RU Windows IT Pro Мир ПК DGL. RU Лечащий врач Publish What Hi-Fi Классный журнал Понимашка Мир ЦОД BIG DATA RUS. Средство массовой информации - www. Свидетельство о регистрации СМИ сетевого издания Эл. Выдано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций Роскомнадзором.
Проблемы интеграции корпоративных информационных систем. Проблемы интеграции не ограничиваются только программным обеспечением, они охватывают всю ИТ - инфраструктуру предприятия, которая должна обеспечить возможность интеграции не только программным компонентам КИС, но её пользователям, информации и обслуживаемым ею бизнес-процессам без потери гибкости и масштабируемости. Кусов Алексей Александрович аспирант Санкт-Петербургский институт управления и права. Так что, типичная информационная среда автоматизации - это несколько программ, разрабатывавшихся в разное время разными разработчиками на разных платформах в соответствии с тем пониманием бизнес-процессов, которое существовало во время их разработки. Проблема заключается в том, что эти программы начинают функционировать как отдельные технологические островки, независимые друг от друга, с отдельными, часто несопоставимыми данными, отсутствием квалифицированного обслуживающего персонала, технической документации и служб сопровождения, без которых невозможно развитие и совершенствование систем автоматизированного управления. При лоскутной автоматизации практически невозможно увидеть реальную картину деятельности предприятия. Следовательно, невозможно и сколько-нибудь обоснованно планировать его деятельность и финансовые результаты. Результатом "лоскутной" информационной среды является низкая эффективность работы ее составляющих, увеличение затрат на поддержку, эксплуатацию и развитие, невозможность обеспечить требуемую информационно-учетную и аналитическую поддержку бизнес-процессов на должном уровне и в срок и, соответственно, потери в эффективности бизнеса. Именно поэтому у руководства компаний все чаще возникает задача интеграции существующих на предприятии "лоскутных" программных продуктов в единую комплексную, интегрированную Корпоративную Информационную Систему. Однако, проблемы интеграции не ограничиваются только программным обеспечением, они охватывают всю ИТ - инфраструктуру предприятия, которая должна обеспечить возможность интеграции не только программным компонентам КИС, но её пользователям, информации и обслуживаемым ею бизнес-процессам без потери гибкости и масштабируемости, необходимых для адаптации этой системы к изменяющимся требованиям бизнеса. Попытки решить интеграционную проблему исходят и от поставщиков корпоративных программных продуктов. Они утверждают, что продукты класса ERP ERP II, CSRP и BPM "автоматически" снимает проблему интеграции. В качестве подтверждения своей теории они приводят следующие аргументы:. Однако, практика показала несостоятельность их теорий. В действительности, ни одна из этих систем не в состоянии решить все задачи, стоящие перед предприятием. Следовательно, потребуется приобретение дополнительного модуля или разработка собственного приложения, реализующего необходимую функциональность, и, как результат, проведение интеграции. Кроме того, утверждение, что ERP-система уже интегрирована, достаточно условно, поскольку при установке новой версии любого модуля, входящего в ERP-систему, требуется обновление и других модулей. Поэтому поставщики должны обеспечить возможность внедрения различных версий своих приложений - что также требует интеграции. Кроме того, на предприятиях всегда остается несколько "устаревших" приложений. Дело в том, что на внедрение всех модулей ERP-системы нужны годы, и пока они устанавливаются, используется существующие приложения, то есть снова необходима интеграция. Наконец, слияния и поглощения предприятий являются источником возникновения интеграционных проблем, так как на предприятиях часто используются ERP-системы от разных поставщиков, что может потребовать их интеграции. Интеграция "каждый с каждым". Это традиционный подход к интеграции прикладных программ. Он состоит в создании специализированных интерфейсов обмена данными для каждой пары обменивающихся приложений. Такой подход хорош для небольшого числа приложений. При большом их числе он практически не работает. Кроме того, он не позволяет строить качественно новые запросы к обьединенным данным, то есть качественного выигрыша от объединения данных нет. Интеграция на уровне пользовательских интерфейсов. Подход основан на том, что приложения могут использовать друга так же, как их используют люди, а именно с помощью специальных инструментов через пользовательский интерфейс screen scraping. Наиболее распространенный вариант - HTML-scraping, при котором специальный инструмент например, Composite Application Platform предприятия CrossWeave , идентифицирует компоненты HTML-документа, полученного в результате работы веб-приложения, и предоставляет эти компоненты для повторного использования и интеграции. Такой подход может успешно применяться для сравнительно простых Web - приложений, но в последнее время он все больше вытесняется Web- сервисами. Интеграция на уровне данных. Один из самых распространенных в настоящее время подходов - создание хранилищ данных datawarehouses. Подразумевает поддержку данных в специальных хранилищах независимо от породившей их бизнес-логики. Доступ к хранилищам могут получать различные приложения. При этом подходе важное значение принимает наличие хорошо документированной и редко изменяющейся модели данных. Есть у этого подхода и свои недостатки, связанные в первую очередь с:. Интеграция на уровне информационных ресурсов. Такую методику интеграции обеспечивают ECM-технология, Они позволяет быстро объединять разрозненные информационные системы предприятия, связывая их на уровне потоков информации, связывающих рабочие бизнес- процессы. При этом каждый исполнитель таких процессов вовремя получает свои задания и уведомления в случае нарушения регламента , а руководители имеют возможность контролировать ситуацию. Однако мало только дать задание человеку, нужна еще информация для принятия решений. Более того, часто недостаточно только оперативной информации, например, по конкретному заказу — требуется доступ к информационному хранилищу, чтобы, например, просмотреть документы по прошлым заказам, переписку с клиентом, поднять текст договора и т. Ни аналитики, ни тем более сама система не смогут догадаться, какие именно документы вам понадобятся в конкретный момент; их нельзя просто прикрепить к заданию и доставить сразу весь пакет. Вот почему вместе со средствами автоматизации бизнес-процессов в ECM-системах активно используются системы управления документами и другие компоненты общей системы. В российской практике ближе всего к понятию ECM находятся системы электронного документооборота СЭД. С другой стороны, в качестве ECM можно рассматривать многофункциональные платформы для разработки решений в области управления информацией, такие как Lotus Notes или EMC Documentum. Интеграция на уровне корпоративных приложений. Интеграция на уровне приложений EAI, Enterprise Application Integration подразумевает совместное использование исполняемого кода, а не в отличие от предыдущего подхода внутренних данных приложения. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего программного обеспечения ПО. При таком подходе из этих компонентов создается универсальное программное ядро, которое используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции. Полученную в результате систему легче поддерживать и расширять. Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений. Кроме того, EAI интегрирует приложения, не внося в них каких-либо модификаций, что гарантирует отсутствие ошибок в их работе. Недостатком этого подхода является сложность заранее точно не оцениваемая и, соответственно, стоимость работ. Интеграция при помощи Web-сервисов SOA. Самый современный и быстро развивающийся подход к интеграции приложений. Он основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным. Например, используя стандартный протокол доступа к объектам SOAP Simple Object Access Protocol , браузер пользователя может сравнить цены на нескольких сайтах и предоставить клиенту сравнительный отчет. Web-сервисы напоминают подход EAI, но с одним существенным отличием - они существенно более стандартизованы. В большинстве случаев EAI -решения разрабатываются как частные для связи конкретных продуктов. Соответственно, подключить к существующему EAI -решению еще одну систему - большая, трудная и долговременная задача. Поскольку Web-сервисы основаны на общих для W3C -консорциума стандартах, они могут работать всюду, где можно использовать WWW-технологии. Большинство предприятий не могут позволить себе отказаться от существующей инфраструктуры и заново реализовать интеграцию. Как правило, не следует отказываться от многих наследованных приложений даже от мэйнфреймов , но их можно существенно улучшить, если интегрировать присущие им деловую логику и данные с другими приложениями. Один из способов объединения различных наследованных приложений предлагает специальное промежуточное ПО. С его помощью формируется интерфейс мост между двумя разными системами. Такое ПО объединяет два или несколько изолированных приложения, позволяя им взаимодействовать между собой, а также свободно обмениваться данными рис. В его состав могут входить программы, написанные программистами предприятия, либо готовые модули. Существуют несколько видов подобных систем. Одним из важных приложений промежуточного ПО является объединение клиента и сервера в процессе клиент-серверных вычислений, а также улучшение связи web-сервера с данными, хранящимися на другом компьютере. Благодаря этому пользователи могут запрашивать данные из компьютера, в котором они хранятся, используя формы, отображаемые на экране web-браузера, в результате чего web-сервер может возвращать динамические web-страницы, выполняя запросы пользователей. Одна из ключевых проблем при создании КИС— интеграция объектно-ориентированного подхода и распределенных вычислений. Этим занимаются многие разработчики, среди которых выделяется международный консорциум OMG Object Management Group. Им была предложена архитектура управления объектами ОМА, лежащая в основе стандарта CORBA Common Object Request Broker Architecture , которая обеспечивает совместимость и возможность взаимодействия объектов в компьютерной сети. Основная идея этой архитектуры заключается в представлении любой задачи в форме взаимодействия объектов, распределенных по различным компьютерам. Объектная модель CORBA определяет порядок взаимодействия между клиентами и серверами рис. Клиенты — это приложения, запрашивающие услуги, а серверы — приложения, предоставляющие эти услуги. Для нового стиля производства характерны меньшая иерархичность в организации и управлении, децентрализация управления, гибкий менеджмент, опирающиеся на мгновенно получаемую информацию. Менеджер нового типа опирается на неформальное общение и набор заранее определенных целей в большей мере, чем на формальное планирование , гибкую организацию команд и лиц, работающих над определённой задачей, и ориентацию на потребителя для достижения координации во взаимодействии работников. В структуре управления предприятием появился дополнительный уровень - уровень управления знаниями, а в ИТ-подразделениях — отделение по управлению корпоративными знаниями. Менеджер нового образца апеллирует к знаниям, изучению и принятию решений, заставляющих отдельных работников обеспечивать успешную работу предприятия. Такой стиль управления делает вполне возможным внедрение новейших информационных технологий управления и, в частности, технологий искусственного интеллекта. Однако, большинство традиционных предприятий, особенно в России, было и остается иерархически организованными образованиями с централизованным управлением, которые используют стандартные операции для массового производства продукции или предоставления услуг. Они базируется на формальных правилах, формальном планировании, жестком распределении труда. Вот почему, для всё углубляющейся интеграции в мировую экономическую систему, России необходим резкий качественный скачок в области организационного управления за счёт внедрения современных корпоративных информационных систем. Успешное решение этой стратегической задачи требует также усилить подготовку кадров в этом направлении. Федеральная служба по надзору в сфере связи и массовых коммуникаций. ГЛАВНАЯ О ЖУРНАЛЕ РЕДАКЦИЯ АВТОРАМ КОНТАКТЫ. Любая ERP-система автоматизирует большинство процессов: Все эти приложения уже "интегрированы", поскольку поставляются одной компанией-разработчиком. Таким образом, внедрение ERP-системы снимает необходимость вкладывать значительные средства в интеграцию приложений. Возможность осуществлять оперативное управление компанией. Сохранение инвестиций в обучение персонала, имеющиеся системы и оборудование. Возможность осуществлять планомерное развитие общекорпоративной информационной системы, интегрируя в нее функциональные компоненты, исходя из приоритетов развития бизнеса предприятия и потребностей функциональных подразделений, то есть возможность синхронизировать развитие системы с развитием бизнеса. Возможность при необходимости заменить любой функциональный компонент другим, более соответствующим текущим бизнес-потребностям. Возможность инвестировать в развитие информационных технологий не сразу, а поэтапно, на каждом этапе соотнося вложенные средства с полученным бизнес-эффектом. Возможность снижения общей стоимости автоматизированного рабочего места, включая затраты на создание системы, поддержку рабочих мест и обучение пользователей. Резкое снижение времени сбора информации, необходимой для принятия управленческих и бизнес - решений. Ликвидация противоречивости данных от различных служб. Сокращение времени и трудозатрат на ведение учетных операций. Ведение консолидированного управленческого учета по нескольким филиалам. Снижение затрат рабочего времени на формирование промежуточных отчетов, на сверку информации между подразделениями. Питер; — с. Производственный и информационный менеджмент , 8-е изд.: Инвестиции Математические и инструментальные методы экономики Логистика Макроэкономика Маркетинг Отраслевая экономика Предпринимательство Региональная экономика Рецензии Теория систем Теория управления Управление качеством Финансы и кредит Ценообразование Экономика природопользования Экономика труда Экономическая безопасность Экономический анализ.
Почта россии расписание работы отделений
Город видное какое метро
Как сделать робота друга
Круглое лицо какие стрижки подойдут мужчины
Причины исторического развития