Реорганизация ИТ-служб организации в период антикризисного управления.

Реорганиза́ция юридического лица – прекращение или иное изменение правового положения юридического лица, влекущее отношения правопреемства юридических лиц, в результате которого происходит одновременное создание одного, либо нескольких новых, и/или прекращение одного, либо нескольких прежних (реорганизуемых) юридических лиц. Осуществляется в форме слияния, присоединения, разделения, выделения или преобразования.

В области создания и эксплуатации корпоративных ИС основополагающими методиками и концепциями, обеспечивающими интегрируемый взгляд на этот сложный комплекс вопросов является представления об архитектуре и стратегии ИТ.

Методы управления ИС - службами постоянно изменяются, также как и модели взаимодействия ИТ и бизнеса.

Основной причиной реструктуризации ИТ - служб в течение последних 3-х лет усиление ориентации на бизнес, снижение затрат, введение инноваций. В международной практике и в России распространены следующие технологии применяемые для повседневной работы или реорганизации ИТ – службы предприятия.

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

ИТ как центр затрат остались в прошлом. Принятие технологических решений без ясной связи с приоритетами бизнеса неприемлема. В период кризиса ИТ – службы реорганизуются с целью улучшить бизнес-ориентацию.

Методология IT и COBIT ориентирована на эффективное управление основаны на процессном подходе и в большей степени, чем остальные методологии оперируют общей терминологией.

ITIL - это методология. Возникла в 80-х годах. Она позволит вам обеспечить эффективное функционирование служб Информационных Технологий (ИТ), удовлетворение нужд бизнес-пользователей, стабильное и предсказуемое развитие информационной системы. ITIL (Information Technology Infrastructure Library) предусматривает подробный список процессов, которые позволяют компаниям управлять своими информационными технологиями. Она объединяет передовой практикой стратегий, чтобы помочь ИТ поддерживать уровень обслуживания бизнеса. Процедуры, определенные в этой методологии охватывают все области ИТ-инфраструктуры и в равной степени относятся к любой технологии, которую вы используете. Есть множество способов сделать деятельность ИТ-службы прозрачной. Но лишь один из них поможет понять все аспекты работы ИТ-службы не только профессионалу в области ИТ, но и владельцу бизнеса, который не имеет специального образования. Это – ITIL. При этом чтобы разобраться с работой ИТ-службы в компании, не обязательно внедрять всю систему ITIL сразу. Достаточно только части этой методологии. Согласно ITIL ИТ-служба должна предоставлять услуги. Это означает, что положительный результат от ее использования измеряется в эквиваленте услуг, их качестве и стоимости. Значит, в первую очередь необходимо разобраться с тем, что такое услуги, из чего они состоят, как создаются и что от них может получить бизнес.

CobIT – свод открытых документов, включающий в себя международные и национальные стандарты в области контроля управления, аудита, а также обеспечения безопасности ИТ. CobIT это высокоуровневый стандарт, который создавался для управления и контроля ИТ с точки зрения цели бизнеса и выдвигаемых требований.

Опираясь на CobIT компания сама может определить какие области деятельности нужно контролировать для достижения цели, отслеживать выполнение параметров.

В отличие от ITIL в стандарте CobIT не сказано каким образом следует организовать эту деятельность и правильно построить процессы. Система контроля CobIT может использоваться при проведении внутреннего и внешнего аудита ИТ – подразделения или ИТ – компании. Результаты можно использовать для определения стратегии дальнейшего развития компании.

ITIl и CobIT не исключают, а дополняют друг друга.

При создании CobIT учитывались идеи и терминологии ITIL, что позволяет их использоать совместно.

 

Сервис-ориентированная архитектура. Интеграция и взаимодействие информационных систем предприятия. Концепция сервис-ориентированной архитектуры. Типовое инфраструктурное программное обеспечение для интеграции данных.

Сервис-ориентированная архитектура: основные понятия

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией федеративного Хранилища данных. Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:

SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.

SOA - это не технология, а способ проектирования и организации информационной архитектуры и бизнес-функциональности.

Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означает построения приложений в соответствии с принципами SOA.

Джерими Уэстерман дает следующее определение SOA: это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде. Применение этого подхода требует от разработчиков проектирования приложений как набора сервисов, даже если преимущества такого решения сразу неочевидны. Разработчики должны "выйти за границы" своих приложений и подумать, как воспользоваться уже существующими сервисами, или изучить, как их сервисы могут быть использованы их коллегами.

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

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

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

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

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

Следствиями отсутствие должного решения проблемы интеграции являются:

· повторный ручной ввод данных (справочники, данные об отгрузках, финансовые транзакции и т.п.);

· многократные и бесконечные «сверки и корректировки» не исключающие ошибок;

· непомерные затраты на формирование сводной отчетности;

· неприемлемые сроки и себестоимость выполнения даже обыденных задач.

 

Общие цели интеграции приложений можно сформулировать следующим образом:

· уменьшить стоимость эксплуатации совокупности приложений предприятия;

· увеличить скорость выполнения типичных задач или гарантировать сроки их выполнения;

· поднять качество выполнения задач за счет формализации процессов и мини­мизации человеческого фактора, как основного источника ошибок.

В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Например: «обеспечить формирование финансо­вой отчетности предприятия в срок не более одной недели после завершения финансового периода»; «уменьшить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, задействованного для поддер­жания в актуальном состоянии справочников и классификаторов, с 20 до пяти че­ловек». Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказыва­ются в выигрышном положении с точки зрения обоснования перед людьми, при­нимающими решение о финансировании проектов: расчет показателей возврата инвестиций для таких проектов может выглядеть достаточно привлекательным.

Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Одна­ко для интеграционных проектов такая заинтересованность жизненно необходи­ма. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т.д. Согласование и формализация требований раз­ных подразделений становится очень трудной задачей; отсутствие среди «идео­логических лидеров» проекта человека, которому подотчетны все задействован­ные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.

Взаимодействие интегрированных приложений. Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщени­ями. В этом списке нет прямого обмена данными между базами данных приложе­ний: этот метод ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загруз­ке накладных пересчитывать товарные остатки). Прямой обмен данными, кото­рый обычно выполняется средствами класса ETL (extract, transfer, load) или само­дельными утилитами, обычно такой возможности не предоставляет.

Интеграция данных (англ. — Data integration) — процесс объединения данных из различных источников для получения их согласованного представления, в широком смысле — процесс организации регулярного обмена данными между различными ИС предприятия.

Залогом успешной интеграции приложений и бизнес-процессов является интеграция данных и систем баз данных. Стандартами интеграции являются те форматы, которые поддерживают использование и распространение информации и бизнес данных, т.е. стандарты являются основой для проведения интеграции корпоративных приложений. К ним относятся COM+/DCOM, CORBA, EDI, JavaRMI и XML.

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

⇐ Предыдущая891011121314151617Следующая ⇒

Поделиться: