+7 (495) 956-79-28
ГлавнаяПресс - центрСтатьи и интервьюКорпоративное информационное пространство: задачи и реализация

Корпоративное информационное пространство: задачи и реализация

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

Какие же системы должны входить в такое пространство и каким требованиям они должны удовлетворять? Рассмотрим общую структуру информационного пространства, представленную на рисунке.

В ее основании находится аппаратная компонента (аппаратная платформа), в задачи которой входит физическое хранение, обработка и передача информации в рамках всего информационного пространства организации.
Средний уровень (СУБД, РСУБД) обеспечивает программную ресурсную поддержку верхнего уровня, непосредственно реализующего возможность работы с данными. В него могут входить системы управления базами данных (как реляционного, так и нереляционного типа), к примеру, Microsoft MS SQL, Oracle, IBM Lotus/Domino, DB2. Также в этот уровень может быть включена инфраструктурная поддержка системы обеспечения информационной безопасности, такая как Public Key Infrastructure (PKI).
Верхний уровень состоит из конечных приложений, функционал которых и составляет то самое корпоративное информационное пространство с набором задач, определенных при проектировании системы, которое обеспечивает жизнеспособность предприятия/организации.

Перечислим основную общую структуру верхнего уровня такого пространства:
  • система электронного документооборота (СЭД) с обязательной поддержкой основных процессов общего и частного (кадрового, конфиденциального) делопроизводства, обеспечивающая полный жизненный цикл работы с документом - от создания его проекта до помещения в ведомственный архив организации;
  • система автоматизации бизнес-процессов (Workflow), обеспечивающая решение общих, типовых задач, возникающих в процессе жизнедеятельности организации (к примеру, работа с заявками, доверенностями и т.д.). На основе workflow-модуля могут быть построены и более сложные комплексные системы, объединяющие Workflow, например с функционалом СЭД — система поддержки Системы Менеджмента Качества (СМК) на предприятии; либо с функционалом 1С — система управления командировочной отчетностью;
  • система управления взаимоотношениями с клиентами, или Customer Relationship Management (CRM), осуществляющая поддержку всего цикла работы с клиентом (от первого контакта до контроля дебиторской задолженности контрагента и лимита на отгрузку продукции);
  • шлюзовой модуль, обеспечивающий пересылку и обмен данными между программными системами верхнего уровня. Так, система поддержки ведомственного архива должна обеспечивать возможность приема документов из СЭД, а CRM - контролировать и отображать дебиторскую задолженность контрагента по базе 1C.

В верхний уровень может также входить достаточно большое количество разнообразных программных систем, назначение и особенности работы которых определяются спецификой организации.
Проблематика, возникающая при использовании такой модели, проявляется лишь со временем. В условиях бурно развивающейся экономики требования к корпоративной информационной системе (КИС) зачастую многократно изменяются еще на этапе ее проектирования. Что же делать в ситуации, когда любая проектируемая система к моменту её ввода в эксплуатацию гарантированно не удовлетворяет запросам заказчика? Решение простое. Требования, как и архитектура системы, должны строиться не на основании тех модулей, которые войдут в её состав на этапе проектирования, а на формулировках того, что она должна обеспечивать с учетом масштабируемости. Таким образом, мы приходим к более современной архитектуре информационных систем.

В основном указанные проблемы возникают вследствие отсутствия более-менее четких архитектурных стандартов в области информационных технологий. И для преодоления подобных негативных аспектов требуется не только стандартизация разработки систем в целом, но и доведение их разработки до модульной концепции, где единичный модуль — стандартизованный компонент, решающий небольшую задачу в рамках более крупной. Таким модулем может, к примеру, являться реализация микрозадачи "согласование документа", который может быть использован и в СЭД при подготовке организационно-распорядительных либо исходящих документов, и в финансово-бухгалтерской системе, например при согласовании заявки на закупку товарно-материальных ценностей. Очевидно, что для реализации данной концепции должна появиться и система, которая свяжет их воедино. Как частный пример такой системой может являться workflow-движок, обеспечивающий запуск, поддержку работы и передачу информации и от модуля к модулю, от подсистемы к подсистеме.

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

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

Целями архитектуры SOA, прежде всего, являются:
  • архитектура как таковая, не привязанная к какой-то определённой технологии, независимая от используемой вычислительной платформы;
  • независимость организации системы от применяемых языков программирования;
  • использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним;
организация сервисов как несвязанных либо слабосвязанных компонентов для построения систем.

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

Компоненты программы могут быть распределены по разным узлам информационной сети и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения со страндартизованным интерфейсом, обеспечивающим лёгкую взаимосвязь при их сопряжении. Программные комплексы, разработанные в соответствии с SОА, часто реализуются как набор Web-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP и т. п.)

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

SОА хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и системных интенграторов предлагают инструменты и решения на основе SОА (например, платформы IBM NetSphere, SAP NetWeaver, Tibco).

При построении ИТ-архитектуры на основе SОА основная сложность заключается не только в типизации сервисов, но и в изменении подходов к управлению организацией с функционально-ориентированных на процессно-ориентированные. А это уже вопрос не технологий, а уровня менеджмента в компании. Крупные российские компании сейчас активно занимаются перестройкой собственных моделей управления, в том числе приводя системы менеджмента в соответствие с серией стандартов ISO 9000, которые как раз и делают необходимой предварительную постановку процессного менеджмента в организации. Типизация бизнес-процессов совсем не обязательно будет поддержана самим бизнесом, однако изменение корпоративной культуры и взаимопонимание бизнеса и ИТ являются непременным требованием для эффективной реализации SОА в рамках построения корпоративной информационной сети. Прежде чем переходить к SОА, необходимо поднять зрелость процессов на несколько уровней, что для большинства средних и крупных отечественных компаний представляет высоту, достижимую лишь через несколько лет.

Модуль Email-маркетинга в настоящее время недоступен.

Ресурс 1 Ресурс 1