Метод интеграции сторонних систем анализа и обработки данных в существующую ИС-архитектуру компании

SPSS работает только с плоскими, структурированными таблицами.

Главная задача, которую решает SPSS, и которая коррелирует со многими областями деятельности Службы управления клиентских данных: выявлять закономерности в данных.

Прикладные задачи, решаемые с помощью SPSS:

ѕ поведенческая сегментация Клиентов;

ѕ построение прогностических моделей для стимулирования дополнительных продаж;

ѕ построение прогностических моделей для поиска Клиентов, склонных к оттоку.

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

На основании витрины данных, строятся более мелкие таблицы для обучения и применения моделей. Построенные в SPSS модели будут использоваться как средство обоснования принятия решений:

ѕ модели для сегментирования клиентов будут использоваться для формирования посылов коммуникации, разработки новых продуктов на основании сегментов и для них;

ѕ модели для допродаж услуг будут использоваться для приоретизации предложений Клиентам, для оптимизации допродаж и увеличения их эффективности;

ѕ модели по оттоку будут использоваться для работы с проактивным сохранением Клиентов, редуцировании возможного оттока.

Результатом моделирования (см. рисунок 6) является список Клиентов с метками принадлежности классу, либо вероятности совершения Клиентом целевого действия. Далее список обрабатывается и осуществляется выбор наиболее подходящих Клиентов для осуществления коммуникации.



Рисунок 6. Интерфейс SPSS. Построенная модель на основе витрины данных (внутренний корпоративный источник)

Важно, чтобы показатели отражали основные точки взаимоотношений Клиента с компанией и характеризовали его:

ѕ состав услуг, и их использование Клиентом;

ѕ активность Клиента;

ѕ платежи;

ѕ проблемы с услугами;

ѕ история обращений;

ѕ пользование программой лояльности;

ѕ рекламные акции, примененные к клиенту;

ѕ статистика по «телесмотрению»;

ѕ данные об оборудовании.

Каждое поле в витрине данных соответствует отдельным показателям. Общее количество показателей витрины данных SPSS - 600. В рамках сопровождения проекта «Витрина данных для SPSS» возможна доработка реализованных показателей и создание новых показателей по требованию бизнеса.

Обоснование актуальности разработки витрины данных SPSS

На текущий момент существует подобная витрина данных SPSS, однако она является устаревшей и содержит малое количество показателей (около 200). Существующая витрина данных доступна на сервере SA, название таблицы - ma_fact_stat_all.

Существующая витрина данных SPSS логически выстроена с уровня договора. Реинжиниринг витрины необходим вследствие того, что все коммуникации с Клиентом переходят на более высокий уровень абстракции - на Клиента. Таким образом, при создании новой витрины данных выделен отдельный блок «Клиент». Графически путь коммуникаций на Клиенте представлен на рисунке 7.

Рисунок 7. Логика перехода на более высокий уровень абстракции

На текущий момент услуги договора привязаны к договору и, в случае, если Клиент заключит новый договор, все услуги будут привязаны к новому договору. Таким образом, не обеспечивается атомарность данных на логическом уровне и удобство работы с данными Клиента для сотрудника компании.

В новой витрине данных необходимо использовать логику привязки к уровню Клиента. Так, при заключении нового договора услуги со всех договоров будут привязаны к одному Клиенту.

Все данные в витрине собираются в разрезах Клиента и месяца.

Общие требования к витрине данных SPSS

К витрине SPSS предъявляются следующие общие требования:

ѕ таблицы должны хранить данные по параметрам в ежемесячном разрезе по уникальному идентификатору, аналогично текущей витрине SPSS;

ѕ таблицы должны обновляться за предыдущий месяц до 10-го числа текущего месяца;

ѕ требования к характеристикам Клиентов, данные по которым должны быть представлены в витрине SPSS:

- договоры физических лиц, которые хотя бы однажды были активны (проверка на наличие активного терминального ресурса/активации приложения на договоре) в предыдущие 2 года, а также все новые заключенные договоры;

ѕ в витрину не должны попадать данные по Клиентам, у которых:

- 2 года отсутствует активность по договорам, т.е. все их договоры являются расторженными или не подключенными;

- существуют следующие атрибуты договора: «Технологические», «Технические» и «Тестовые» договоры;

- юридические лица (Клиенты блока b2b);

- договоры, которые проходят проверку на двойные без привязки к сроку и не проявляют активности, например, отказные договоры (по которым найден факт расторжения договора);

ѕ при проведении обновлений таблицы, после полного расторжения клиента, новую информацию о договорах в таблице хранить 3 месяца, после исключать из будущих обновлений.

2.2.2 Описание проекта по внедрению продукта IBM Campaign management

Задачей проекта по внедрению Campaign Management является автоматизация полного цикла проведения кампаний, включая:

ѕ сегментацию и отбор Клиентов;

ѕ применение коммуникационной политики;

ѕ назначение сегментам предложения;

ѕ определение каналов коммуникации и их последовательности;

ѕ передача заданий на коммуникацию в канал;

ѕ сбор и хранение откликов;

ѕ подготовка отчетов по эффективности кампаний.

В результате внедрения ожидается:

ѕ увеличение объемов вторичных продаж, которое достигается за счет:

- увеличения количества запускаемых кампаний;

- сокращения времени на подготовку проведения кампании (time to market);

- увеличения процента откликнувшихся Клиентов;

- увеличения количества используемых каналов;

ѕ повышение эффективности кампаний, которое достигается за счет:

- сокращения расходов на нерезультативные контакты при проведении таргетированных кампаний;

- более тонкого сегментирования клиентской базы;

- снижения издержек на коммуникации;

- анализа результатов проведения кампаний;

ѕ увеличение лояльности клиентов, которое достигается за счет:

- уменьшения перекоммуникации с клиентом за счет применения контактной политики;

- использования наиболее релевантных каналов для каждого клиента;

- выстраивания персонального консистентного диалога с клиентом;

ѕ анализ результатов проведения кампаний, которое достигается за счет:

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

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

- выбора наиболее эффективных кампаний при проведении пилотов.

2.2.3 Анализ места подключаемых систем в общей архитектуре серверов компании

В данном пункте представлено описание подключенных систем к общей инфраструктуре ИС компании.

В случае IBM SPSS:

Вследствие того, что сбор данных с городов и их расчет в пакетах на builddev и designdb сильно нагружает схему, принято решение перенести расчет показателей на схему SA. Таким образом, данные не собираются по городам и реплицироваться на SA, весь расчет сразу будет происходить на SA. На SA все таблицы с данными (clients, agreements и т.д.) имеют поле billing_id.

Для отладки реализованных показателей необходимо создавать представления на builddev. Расчет витрины данных, ориентированной на Клиента осуществляется на сервере SA. Показатели, логика которых реализована на биллингах городов после проката по всем городам, реплицируются на SA. Архитектура решения витрины данных для IBM SPSS Modeller представлена на рисунке 8.

Рисунок 8. Архитектура решения витрины данных SPSS



Единая система управления кампании и коммуникациями на базе продукта IBM Unica Campaign имеет следующую физическую архитектуру, представленную на рисунке 9.

Рисунок 9. Архитектура Campaign Management

Пользователи авторизуются с использованием своих доменных УЗ и доменных паролей в системе по прямой ссылке http://eskk-app1.hq.ertelecom.ru:9080/unica. Пользователи, который не имеют доступа к системе могут обратиться к администратору системы и запросить создание учетной записи и выдачи соответствующих прав. Запрос на добавление УЗ должен сопровождаться подтверждением от руководителя подразделения (в тексте электронного письма, сообщением в Lync, звонком администратору). Более подробно данный процесс описывается в п.5 настоящего документа.

Система IBM Campaign имеет 2 сервера приложений - Application (eskk-app1.hq.ertelecom.ru) и Analytics (eskk-alt1.hq.ertelecom.ru). Сервер Application предназначен для предоставления пользовательского web-интерфейса и логики его работы. Составляющими для него являются веб-приложения Marketing Platform, Campaign. Сервер Analytics - ответственный за выполнение логики диаграмм кампаний, его составляющая - Campaign Server. Система сообщается с сервером SMTP с использованием TCP порта 25, а с сервером LDAP по 3268 порту. Синхронизация проходит с участием компоненты Marketing Platform (Platform). Данная компонента так же общается напрямую с таблицами внутри БД DWH c использованием порта 1521.

Компонента Campaign сервера Application прослушивает TCP порт 4664 для синхронизации с слушателем на сервере Analytics. Слушатель системы Campaign - unica_aclsnr позволяет клиентским приложениям, таким как, веб- приложение Campaign, соединяться с аналитическими back-end процессами. Слушатель автоматически вызывает отдельный процесс unica_acsvr для каждого залогированного пользователя и для каждой активной диаграммы. Например, если один пользователь залогинился в системе и затем открыл диаграмму, слушатель порта создаст 2 экземпляра процесса unica_acsvr. Также слушатель системы, используя порт 1521, общается со следующими объектами в БД DWH:

CMDM - витрина данных (DWH), используется для сегментации и выявления целевых действий;

Campaign - системные таблицы, истории откликов и контактов;

Exchange - обеспечивает интеграцию с каналами связи;

Stage - хранение временных таблиц для данных по откликам 1 и 2 типа;

Unica_user - служит для подключения пользователей к БД, хранит временные данные и промежуточные значения, созданные в системе.

Также используется БД SA для сегментации по неагрегированным данным.

2.3 Оценка проекта до изменений

Методологии оценки проекта описаны в приложении 1, приложении 2 и приложении 3. Каждая их методологий описана на примере проекта Campaign Management. В п. 3.3 представлена оценка проекта Campaign management после внедрения единой интеграционной шины.



Глава 3. Разработка решения по гибкой интеграции сторонних систем в ИТ-инфраструктуру компании

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

В качестве вариантов интеграции рассмотрены следующие:

ѕ данных;

ѕ бизнес-процессов;

ѕ приложений (сервисов).

Предлагается внедрение связки из следующих компонентов:

ѕ Billing + BI - существующие сервера компании (текущая архитектура ИС);

ѕ технологии динамической интерпретации метаинформации;

ѕ особенности адаптивной и инкрементальной архитектуры.

3.1 Интеграционная платформа ESB как средство оптимизации подключения внешних систем к ИТ-инфраструктуре компании

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

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

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

ѕ комплексная связь между существующими системами в ИТ-инфраструктуре компании;

ѕ обеспечение надежной передачи информации между системами;

ѕ обеспечение анализа и трансформации передаваемой информации в соответствии с требованиями принимающей стороны и единой логикой бизнеса.

Рисунок 10.Общая схема взаимодействия систем до внедрения ESB



Рисунок 11.Общая схема взаимодействия систем после внедрения ESB

Согласно бенчмаркинговому анализу западных телеком компаний Vodafone, DeutscheTelecom, Belgacom и др. внедрение интеграционной платформы позволяет достичь эффектов, описанных в таблице 4.

Таблица 4. Эффекты от внедрения ESB в общую ИТ-инфраструктуру компании

Предпосылки	Эффекты
Есть вероятность недоставки сообщения между информационными системами	Гарантированная доставка сообщений
При замене какой-либо информационной системы необходимо перенастраивать связующие интерфейсы между другими системами	При замене какой-либо информационной системы, подключенной к шине, нет необходимости в перенастройке остальных систем
Длительная интеграция новой системы в ИТ-ландшафт компании	Сокращение времени на интеграцию новой системы за счет переиспользования сервисов
Существенные вложения во внешние системы, но невозможность их использования по причине не соответствия с существующим ИТ-ландшафтом компании	Сохранение инвестиций во внешние системы за счет их интеграции, а не отказа от них при построении единого информационного комплекса
Расхождение информации по важнейшим показателям бизнеса	Повышение эффективности оперативного управления бизнесом в результате использования полной непротиворечивой информации из нескольких интегрированных систем
Разработка регламента администрирования для каждой внешней системы	Сокращение затрат на администрирование системы за счет централизации хранения логики преобразования и политик интеграции
	Снижение влияния человеческого фактора и уменьшение количества ошибок при ручном переносе информации из системы в систему; снижение затрат времени на ручной поиск информации в различных системах
	Снижение рисков, связанных с ошибками в работе сетевых и прикладных систем
	Снижение затрат на интеграцию систем, которые будут созданы в будущем, за счет упрощения подключения к КИП и предоставления уже накопленной прикладной информации
	Создание предпосылок для увеличения прибыли за счет построения корпоративной информационной системы, быстро и адекватно реагирующей на изменения

На текущий момент все больше компаний внедряют ESB. Отчет по квадранту Гартнера, 2014. ESB системы (см. рисунок 12).

Рисунок 12. Квадрант Гартнера по сравнению ESB-систем

Ниже на рисунке также представлен отчет Форестер, 2015 по сравнению ESB-систем (см. рисунок 13).



Рисунок 13.Анализ Форестер систем ESB

Данные результаты анализа показывают, что компании IBM, ORACLE являются лидерами на рынке интеграционных решений. Платформы IBM, ORACLE имеют широкий диапазон внедрений во всех сферах деятельности в Европе и на территории РФ.

3.1.1 Готовые решения интеграционной подсистемы

Корпоративная интеграционная подсистема на базе IBM WebSphere Business Integration Message Broker [28] отвечает за выстраивание корпоративной интеграционной подсистемы (КИП), компоненты КИП могут быть модифицированы под конкретные задачи компании, внедряющей решение в зависимости от существующей ИТ-инфраструктуры компании.

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



Рисунок 14. Архитектура КИП с решением ESB - WBI Message Broker

Использование данной архитектуры позволяет решить два основных ограничения, с которыми сталкиваются держатели ИТ-ландшафта компании:

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

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

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



Рисунок 15. Схема актуальности использования транспортного слоя

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



Рисунок 16. Технология передачи сообщений

Ядром решения является программное обеспечение Websphere Business Integration Message Broker, которое обеспечивает обработку передаваемой от приложения к приложению информации и ее интеллектуальную маршрутизацию.

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

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

Прием и передачу сообщений от приложений брокер осуществляет через транспортный слой на базе Websphere MQ (см. рисунок 17).



Рисунок 17. Транспортный слой Websphere MQ

К этому же классу продуктов, называемому ESB, относятся известные на рынке продукты TIBCO, E-mule, и многие другие.

3.1.2 ESB как ключ к внедрению инкрементальной и адаптивной архитектуры

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

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

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

Чтобы следовать принципу повторного использования, потребуется выстроить методологию и прозрачный подход в части управления ИТ, начиная с инфраструктурного уровня и заканчивая пользовательским уровнем. Примерами следов такой гармонизации могут стать появление корпоративной модели данных (Enterprise Data Model, EDM), корпоративной модели сервисов (Enterprise Service Model, ESM), корпоративной модели ролей (Enterprise Role Model, ERM) и т.д. Каждая из этих моделей гармонизирует и унифицирует свою функциональную область. Любое новое изменение обязательно должно проходить контроль наличия места для него в описанной модели [1].

Вторым важным принципом адаптивной архитектуры является уход от системного программирования. Архитектурная зависимость от таких методов разработки делает развитие дорогим и немасштабируемым. На смену уходящему подходу пришли платформы и CASE-средства.

Внедрение адаптивной архитектуры производится и в организации интеграционного взаимодействия с использованием шины данных. Многие компании делают на уровне шины достаточно много трансформаций данных, в том числе и на уровне моделей. Если эти трансформации делать на уровне системы-источника, унифицировав обмен со всеми системами с помощью одинаковых контейнеров данных, а системам-приемникам самостоятельно разбирать эти контейнеры, забирая из них то, что нужно только им, то можно уйти от постоянной доработки и регрессионного тестирования интерфейсов источников [1].

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

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

3.2 Видение архитектуры ИС компании

Текущая инфраструктура компании совершенствуется, всегда появляются новые системны для подключения и внедрения. Инфраструктура построена на схеме выстраивания архитектуры (см. рисунок 18) следующим образом:

ѕ аналитика;

ѕ ERP (управление ресурсами предприятия);

- бухгалтерия;

- бюджетирование и стратегическое планирование;

- закупки;

- логистика;

- Human Recourses;

- документооборот;

ѕ Billing (ведение тарифных планов, организация расчетов, продукты);

ѕ CRM (взаимоотношения с Клиентами СаД Center, маркетинг);

- взаимодействие с Клиентом;

- контакт-центр;

- Campaign Management (и подсистемы Interact, Optimize);

- BPM;

- система планирования маршрутов техников;

ѕ диспетчеризация оборудования.

Рисунок 18. Общая ИТ-архитектура предприятия

Данная структура является классической, но далекой от российских корпораций (крупных корпораций со сложной ИТ-архитектурой). На рисунке 19 представлено описание текущей ситуации в ИТ-ландшафте компании.

В целом весь ИТ-ландшафт разбивается на несколько функциональных компонент. На нижнем поддерживающем уровне находятся блоки «Информационная безопасность», «Управление сетью», «База знаний». Центральным звеном структуры являются блоки с системами по управлению бизнес-процессами компании, учету договорных отношений с клиентами и управлению коммуникациями с клиентами. На верхнем уровне располагаются блок бизнес-аналитики, включающий в себя сбор, хранение и обработку статистических данных из разных источников и построение отчетности по ним.

Для сравнения на текущий момент в ИТ-ландшафте компании находятся около восьми сторонних информационных систем, в целевой архитектуре (см. рисунок 20 Рисунок является нечитабельным по причине конфиденциальности отображаемых на нем данных.) данное количество стремится к 16. При таком двукратном увеличении мощностей подтверждается актуальность создания решения, способствующего гибкому подключению сторонних систем в общую ИТ-инфраструктуру компании.

Рисунок 19. Общая ИТ-архитектура предприятия «Как есть»

Рисунок 20. Целевая ИТ-архитектура предприятия

3.3 Оценка проекта Campaign Management при использовании предложенного варианта

Прогнозируемая оценка проекта после реализации единой шины данных как прослойки между всеми компонентами ИТ-ландшафта компании выполняется по методу оценки на основе Use-case points на примере проекта Campaign management.

Методология описана в приложении 1. На этапе оценки акторов видно различие от оценки без ESB. Простой актор использует систему по предопределенному API (REST, SOAP, dll), средний использует более сложный и гибкий API, комплексный в большинстве случаев означает взаимодействие с конечным пользователем (см. таблицу 5).



Таблица 5. Оценка акторов

Тип актора	Описание	Степень важности	Значение	Результат
Простой	Внутренняя система с определенным API	1	2	2
Средний	Внутренняя система, использующая интерфейс, основанный на протоколе (HTTP, TCT/IP) или на базе данных	2	4	8
Комплексный	Человеческий ресурс	3	2	6
		Нескорретированный вес актора (UAW)	16

На этапе нескорректированной оценки вариантов использования производится оценка масштаба системы. Поскольку при внедрении ESB сокращается количество интеграционных прецедентов, у большинства транзакций понижается сложность. Оценка транзакций по проекту Campaign management представлена в таблице 6.

Таблица 6. Нескорректированная оценка вариантов использования

Тип прецедента	Описание	Степень важности	Значение	Результат
Простой	1-3 операции	5	9	45
Средний	4-7 операций	10	2	20
Комплексный	>7 операций	15	0	0
		Нескорректированный вес прецедента (UUCW)	85
Нескорректированные очки прецедента (UUCP)= = UAW + UUCW	101=16+85

В качестве транзакта можно использовать количество классов, реализуемых в рамках одного варианта использования. В этом случае ранжирование будет иметь такой вид: простой - меньше 5 классов, средний - 5-10 классов, комплексный - более 10 классов.

Также в качестве транзакта можно использовать количество объектов в БД, изменяемых в рамках одного варианта использования. В этом случае ранжирование будет иметь такой вид: простой - 1 объект, средний - 2 объекта, комплексный - больше или равно 3 объекта.

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

Таблица 7. Оценка технических факторов

Номер фактора	Описание	Степень важности	Присвоенное значение (0-5)	Значение оценки
Т1	Распределенность системы	2	2	4
Т2	Малое время отклика или высокая пропускная способность	1	3	3
Т3	Степень эффективности от использования системы конечным пользователем	1	5	5
Т4	Комплексность внутреннего выполнения процессов системы	1	5	5
Т5	Возможность повторного использования кода	1	3	3
Т6	Низкая степень сложности при установке системы	0,5	2	1
Т7	Низкая степень сложности при использовании системы	0,5	3	1,5
Т8	Возможность экспорта системы на другую платформу	2	0	0
Т9	Возможность сопровождения системы	1	5	5
Т10	Возможность параллельной обработки системы	1	3	3
Т11	Требуемый уровень безопасности системы	1	4	4
Т12	Степень доступа к системе третьими лицами	1	5	5
Т13	Необходимость в обучении пользователей по использованию системы	1	4	4
		Значение фактора технической сложности (TFactor)	43,5
Фактор технической сложности (TCF) = =0,6 + (0,01*TFactor)	1,035=0,6 + (0,01*43,5)

На этапе оценки внешних факторов (см. таблицу 8) производится расчет коэффициента для оценки организационных рисков при разработке. В данном случае при внедрении единой интеграционной шины оценка внешних факторов наоборот показывает увеличение затрат, поскольку в команду разработки будут требоваться более квалифицированный персонал, особенно это касается архитектора, разрабатывающего технические решения совместно с руководителем группы. К примеру, в показатель «Сложности, связанные с языком программирования» запишется значение более высокое по сравнению с оценкой до внедрения ESB, что вызвано необходимостью владения не только pl/sql (основной язык разработки для решения задач проекта Campaign Management), но и JavaSrcript.

Таблица 8. Оценка внешних факторов

Номер фактора	Описание	Степень важности	Присвоенное значение (0-5)	Значение оценки
E1	Опыт персонала в установленном процессе разработки	1,5	2	3
E2	Степень разработанности системы	0,5	4	2
E3	Опыт работы в рамках объектно-ориентированной парадигмы программирования	1	3	3
E4	Способности ведущего аналитика	0,5	3	1,5
E5	Уровень мотивации рабочей группы к выпуску системы	1	3	3
E6	Стабильность требований Заказчика	2	2	4
E7	Наличие персонала, работающего на пол-ставки в рабочей группе	-0,5	0	0
E8	Сложности, связанные с используемым языком программирования	-1,5	5	-7,5
		Значение дополнительных фактора (EFactor)	9
Внешний фактор (EF) = 1.4 + (- 0,03*EFactor)	1,13	=	1,4 + (- 0,03*9)
Установленные очки прецедента (UCP) = =UUCP*TCF*EF	118,12	=	101*1,035*1,13
Усилия в человеко-часах = UCP*PHM	2362,491	=	118,12*20

В результате подсчитываются итоги. Итог = 337,49 (человеко-часы каждого разработчика (7 человек)). После получения оценки необходимо правильно оценить количество часов на один поинт. Существуют классические рекомендации, равные 20-28 часов, однако в действительности оценка может отличаться, в зависимости от следующих факторов:

ѕ степень абстракции при создании диаграмм вариантов использования;

ѕ готовность оценивать тестирование, требования и менеджмент таким же образом.

Таким образом, получена разница в примерно в 91 час. Стоит отметить, что при более точном планировании можно выявить дополнительные факторы, которые окажу существенное влияние на человеко-часы при реализации после внедрения ESB.

Заключение

По завершении работы получены следующие результаты:

ѕ приведено обоснование необходимости создания гибкого метода интеграции новых систем (чаще всего инструментов BI) в общую ИТ-архитектуру компании. Метод интеграции сторонних систем анализа и обработки данных в существующую ИС архитектуру компании позволяет:

ѕ легко внедрять/настраивать системы бизнес-аналитики;

ѕ изменять существующие настройки функционирования подключенной системы;

ѕ не вносить существенных изменений в существующую архитектуру ИС компании при каждом новом внедрении сторонней системы;

ѕ шаблонной интеграции с бизнес-процессами компании.

ѕ в результате анализа особенностей инвестиционных ИТ-проектов «Витрина данных SPSS» и «Campaign Management» проведена оценка длительности и экономической эффективности проектов. Предположено, что при внедрении метода интеграции значительно сократятся трудозатраты исполнителей при подготовке витрины данных и интеграции инструментов в существующие бизнес-процессы компании;

ѕ в результате анализа существующих инструментов и методов интеграции определены наиболее преимущественные для данного случая - динамическая интерпретация метаинформации (семантическая интеграция на основе онтологий предметных областей), а также построение ядра архитектуры и его постепенная доработка подключаемыми сервисами согласно подходам инкрементальной и адаптивной архитектуры [22];

ѕ исследована существующая архитектура ИС компании на верхнем уровне. В продолжение работы архитектура будет проанализирована и актуализирована (полный перечень всех систем, используемые взаимосвязи между ними).

ѕ проанализированы экономические показатели инвестиционных проектов по внедрению систем аналитической обработки данных на примере IBM SPSS и IBM Campaign Management после изменения разработанного метода интеграции;

ѕ разработан метод интеграции подключаемых систем к общей архитектуре ИС компании по следующим требованиям:

ѕ адаптация к существующей архитектуре ИС компании;

ѕ быстрота интеграции кс существующими системами;

ѕ гибкая корректировка конфигурации;



Список терминов и сокращений

Термин/ сокращение	Содержание
API	англ., Application programming interface - Интерфейс программирования приложений
BI	англ., Business intelligence - Бизнес-аналитика
CRM	англ., Customer Relationship Management - Система управления взаимоотношениями с клиентами
ERP	англ., Enterprise Recourse Planning - Система планирования ресурсов предприятия
ETL	Процесс в управлении хранилищами данных, который включает в себя: 1) извлечение данных из внешних источников (Extract); 2) трансформация и очистка (Transform); 3) загрузка в хранилище данных (Load)
MIS	англ., Management Information Systems - Управленческая информационная система
OLAP	англ., OnLine Analytical Processing - Аналитическая обработка в режиме реального времени
SPSS	англ., Statistical Package for the Social Sciences - Статистический пакет для социальных наук
IBM SPSS Modeler	Платформа прогнозной аналитики, позволяющая применять прогнозную информацию при принятии решений на уровне отдельных пользователей, групп, систем или предприятия [29]
UCP	англ., Use Case Points - Методика оценки проектов на основе вариантов использования оцениваемой системы
UML	англ., Unified Modelling Language - Универсальный язык моделирования
WfMS (Workflow Management Systems), CRM (Customer Relationship Management), ERP (Enterprise Recourse Planning)	WfMS (Workflow Management Systems), CRM (Customer Relationship Management), ERP (Enterprise Recourse Planning),
XML	англ., Extensible Markup Language - Расширяемый язык разметки информации, стандарт языка для обмена данными между различными приложениями
БД	База данных
ПО	Программное обеспечение
СППР	Системы поддержки принятия решений
СУБД	Система управления базами данных
ТЗ	Техническое задание
ХД (Data Warehouse)	Хранилище данных

Библиографический список

1. Адаптивная архитектура как средство оптимизации ИТ-бюджета [Электронный ресурс]. [Режим доступа: http://bosfera.ru/bo/adaptivnaya-arhitektura-kak-sredstvo-optimizacii-it-byudzheta, свободный] [Проверено: 25.04.2016].

2. Аналитический обзор Системы бизнес-анализа в России 2014 // TADVISER. [Электронный ресурс] [Режим доступа: http://www.tadviser.ru/index.php/BI] [Проверено: 12.11.2014].

3. Галкин Г. Методы определения экономического эффекта от ИТ-проекта // Intelligent Enterprise, 2005 [Электронный ресурс] [Режим доступа: http://www.iteam.ru/publications/it/section_53/article_2905/] [Проверено 22.01.2015].

4. Из практики интеграции информационных систем и данных. Избегаем трудностей [Электронный ресурс]. [Режим доступа: http://www.prj-exp.ru/integration/integration_practice.php, свободный] [Проверено: 25.02.2016].

5. Инвентарный № ОФЭРНИО 11394-Средства тиражирования данных METAS Replication.

6. Инвентарный № ОФЭРНИО 11378-Программное ядро MDK Suite CASE-системы METAS.

7. Инвентарный № ОФЭРНИО 11379-Система интеграции распределенных приложений Simple BizTalk Server (SBTServer).

8. Интеграция информационных систем предприятия. Взаимосвязь информационных систем предприятия. НОУ Интуит. [Электронный ресурс]. [Режим доступа: http://www.intuit.ru/studies/courses/13833/1230/lecture/24065, свободный] [Проверено: 02.03.2016].

9. Когаловский М.Р. Методы интеграции данных в информационных системах / М.Р. Когаловский // Институт проблем рынка РАН, М. - 2010 - С. 9.

10. Когаловский М.Р. Системы доступа к данным, основанные на онтологиях // Второй симпозиум «Онтологическое моделирование», Казань, октябрь 2010.

11. Кочергов Д. Шпаргалка финансиста // Экономика бизнеса №46 (9260) [Электронный ресурс] [Режим доступа: http://www.eg-online.ru/article/52213/] [Проверено 22.01.2015].

12. Кузнецов Д.П. Метод и средства интеграции онтологий разнородных источников данных в автоматизированных системах управления промышленных предприятий: Автореф. дис. … канд. техн. наук: 05.13.06; [Место защиты: ВлГУ]. Вологда: ВоГТУ, 2013.

13. Лазарев А. В. Ставка дисконтирования с учетом риска и методы ее определения [Текст] / А. В. Лазарев, А. В. Пострелова // Молодой ученый. - 2013. - №6. - С. 373-376.

14. Ложечкин А. Интеграция приложений электронной коммерции с использованием BizTalk Server. М.: Издательский дом «Русская редакция», 2001.

15. Манагаров Р. Обзор методов расчета ставки дисконтирования // Библиотека управления [Электронный ресурс] [Режим доступа: http://www.cfin.ru/finanalysis/math/discount_rate.shtml] [Проверено 22.01.2015].

16. Мусаев А.А. Интеграция автоматизированных систем управления крупных промышленных предприятий: принципы, проблемы, решения. / А.А. Мусаев, Ю.М. Шерстюк // Материалы журнала «Автоматизация в промышленности» №10, М. - 2003 - с. 40-45.

17. Ступников С.А. Формирование базы метаинформации на основе спецификаций канонической модели // С.А. Ступников, Л.A. Калиниченко// ИРИ РАН - С.8.

18. Теленик С.Ф. Каталогизация и интеграция разнородных информационных ресурсов [Текст] // Молодой ученый. - 2013. - №5. - С. 176-179.

19. Хмельнов А.Е. Язык описания данных FlexT:использование динамических типов для описания статических данных / Институт Динамики Систем и Теории Управления СО РАН.

20. Черняк Л. Интеграция данных: синтаксис и семантика. [Электронный ресурс]. [Режим доступа: http://www.osp.ru/os/2009/10/11170978/, свободный] [Проверено: 14.03.2016].

21. Шемсетдинов Т. Динамическая интерпретация метамоделей [Электронный ресурс]. [Режим доступа: https://habrahabr.ru/post/154891/, свободный] [Проверено: 25.01.2016].

22. Шемсетдинов Т. Интеграция информационных систем [Электронный ресурс] [Режим доступа: https://habrahabr.ru/post/117468/] [Проверено: 12.03.2016].

23. Шергин Д. Принципы разработки биллинговой системы // Д. Шергин// [Электронный ресурс] [Режим доступа: http://citforum.ru/operating_systems/linux/billing/] [Проверено: 12.11.2014].

24. Шибанов С.В. Обзор современных методов интеграции данных в информационных системах / С.В. Шибанов, М.В. Яровая, Б.Д. Шашков // Труды международного симпозиума «Надежность и качество». - том I/2010.

25. Bianchini D., Antonellis V. Ontology-based Integration for Sharing Knowledge over the Web [Электронный ресурс] [Режим доступа: http://www.doc.ic.ac.uk/~pjm/diweb2004/DIWeb2004_Part8.pdf, свободный] [Проверено: 25.02.2014].

26. IBM Campaign. Управление маркетинговыми кампаниями для отправки персонализированных сообщений по различным каналам [Электронный ресурс] [Режим доступа: http://www-03.ibm.com/software/products/ru/campaign-management] [Проверено: 12.11.2014].

27. IBM MQ. WebSphere MQ. [Электронный ресурс]. [Режим доступа: http://www-03.ibm.com/software/products/ru/ibm-mq, свободный] [Проверено: 12.04.2016].

28. IBM SPSS. Улучшите результаты работы и эффективность принятия решений с помощью прогностической аналитики [Электронный ресурс] [Режим доступа: http://www-03.ibm.com/software/products/ru/spss-modeler] [Проверено: 12.11.2014].

29. Computerage: улучшить систему, а не бороться с ней // Сетевой журнал: галерея ИТ-проектов. [http://www.setevoj.ru/ITS/comprage78`2002.html].

30. Gemimi Systems [Электронный ресурс] [Режим доступа: http://www.gemini-systems.ru/index.php/finansovyj-sektor/13-integratsiya-informatsionnykh-sistem] [Проверено: 12.11.2014].

31. Ghamdi N., Saleh M., Eassa F. Ontology-Based Query in Heterogeneous & Distributed Data Sources // International Journal of Electrical & Computer Sciences IJECS-IJENS. - 2010 . - №06. С. 86-101.

32. Lahanas S. Semantic Integration. Information Management Magazine, June 2008.

33. Nemirovski G., Albstadt-Sigmaringen A. Data Integration Driven Ontology Design, Case Study Smart City [Электронный ресурс]. [Режим доступа: http://semanco-project.eu/index_htm_files/web_intelligence_june_2013.pdf, свободный] [Проверено: 25.02.2014].

34. Tyner B. Software Cost Estimation With Use Case Points - Introduction [Электронный ресурс] [Режим доступа: http://tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/] [Проверено: 16.04.2015].



Приложение 1. Глоссарий

Термин/ сокращение	Содержание
Клиент	физическое лицо, приобретающее услуги в компании. Юридические лица в данной работе не учитываются.
Отток	момент прекращения Клиентом пользования услугами компании.
Компания	АО «ЭР-Телеком Холдинг» (http://ertelecom.ru/, оператор услуг triple play. Услуги связи - широкополосный доступ в интернет, кабельное и цифровое телевидение, фиксированная телефонная связь - предоставляются под брендом «Дом.ru», для корпоративных клиентов - под брендом «Дом.ru Бизнес», объём абонентской базы 4,2 млн. абонентов, 56 городов проникновения).
Допродажи (кросс-продажи, продажа дополнительного товара)	процесс продажи дополнительного товара/услуги в рамках одной транзакции (общения продавца с покупателем), нацеленная на увеличение средней суммы чека.
Биллинговая система	программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании [24].
Gartner (Гартнер)	Исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий.
Gartner Magic Quadrant (Квадрант Гартнера)	Конкретный анализ какого-либо сегмента рынка, с распределением поставщиков по указанным четвертям; ежегодно компания выпускает несколько десятков магических квадрантов на регулярной основе.
Forrester Research (Форестер)	Международное аналитическое агентство, которое занимается исследованиями рынка информационных технологий.
The Forrester Wave (Отчет Форестер)	Отчет, в рамках которого оцениваются поставщики продуктов и услуги по 100 критериям в зависимости от области исследования в рамках 3 основных секций: «Текущее предложение» (Current offering), «Стратегия» (Strategy) и «Присутствие на рынке» (Market Presence), отражающем кружками разных размеров абсолютный объем продаж (Full vendor participation).



Приложение 2. Оценка экономической эффективности и трудоемкости внедрения сторонних систем

Проведение анализа на предмет определения экономической эффективности ИТ-проекта необходимо для:

ѕ получения технико-экономического обоснования ИТ-проекта;

ѕ обоснования рентабельности планируемых работ;

ѕ определения «узких мест» ресурсного плана проекта;

ѕ решения проблемы соизмерения денежных средств на протяжении всего жизненного цикла проекта (расчетного периода).

Для получения оценки экономической эффективности ИТ-проекта используются различные методы: количественные (финансовые), качественные и вероятностные. Для построения математической модели расчета экономической эффективности ИТ-проекта используются финансовые методы, которые позволят оценить экономическую эффективность ИТ-проекта за счет формализованной цепочки расчета. С помощью финансовых методов предоставляется возможность создавать детерминированные уравнения в модели, а также прогнозировать развитие проекта в рамках конкретного периода.

Цепочка расчета модели оценки экономической эффективности ИТ-проекта состоит из четырех шагов:

ѕ определение прибыли за весь срок реализации ИТ-проекта в текущих ценах;

ѕ оценка устойчивости ИТ-проекта к рискам;

ѕ определение соотношения выгод и затрат;

ѕ оценка окупаемости инвестиций.

На первом шаге производится дисконтирование денежных средств, которое необходимо для приведения будущих денежных потоков к настоящему времени. Дисконтирование денежных средств производится по формуле 1:

,(1)

где Pv - приведенная сумма;

P - не приведенная сумма;

r - ставка дисконтирования;

t - время, когда ожидается сумма.

Определение ставки дисконтирования происходит в два этапа: определение ставки доходности собственного (акционерного) капитала, рассчитанной с использованием модели CAMP, определение средневзвешенной стоимости капитала по формуле 2:

, (2)

где Re - ставка дисконтирования (ставка доходности собственного капитала);

Rm - средневзвешенная рыночная ставка доходности;

Rd - ставка доходности заемного капитала;

Rf - безрисковая ставка дохода;

K - коэффициент эластичности доходности к рынку.

Это укрупненный метод расчета ставки дисконтирования, для чего необходимо определить ставку доходности собственного (акционерного) капитала с помощью модели CAMP.

Средневзвешенная стоимость капитала учитывает стоимость собственного капитала и стоимость заемных средств и рассчитывается по формуле 3:

(3)

, (3)

где WACC - средневзвешенная стоимость капитала;

Re - ставка доходности собственного капитала;

Rd - ставка доходности заемного капитала;

E - рыночная стоимость собственного капитала;

D - рыночная стоимость заемного капитала;

V - суммарная стоимость капитала (V+D), Tc - ставка налога на прибыль.

Показатель чистый приведенный доход отвечает на вопрос насколько будущие поступления оправдывают сегодняшние затраты на ИТ-проект, т.е. показывает наличие/отсутствие прибыли и рассчитывается по формуле 4:

, (4)

где NCF - чистый денежный поток на i-м интервале планирования;

Re - ставка дисконтирования.

Внутренняя норма рентабельности позволяет определить степень надежности проекта, оценка устойчивости проекта к рискам. Величина ставки дисконтирования в точке безубыточности проекта, которая показывает на сколько должны быть велики риски, чтобы свети на нет все усилия заказчика получить прибыль, рассчитывается по формуле 5:

, (5)

где B_t - выгоды проекта за месяц t;

C_t - издержки проекта за месяц t;

I - ставка дисконтирования (ставка рефинансирования + величина рисков, %);

C₀ - первоначальные инвестиции в проект до реализации.

Соотношение выгод и затрат: если величина выгод проекта (прибыль предприятия по итогам реализации проекта) превышает сумму затрат в течение срока выполнения работ, проект считается рентабельным [12], [3], [16], [14]. Соотношение выгод и затрат рассчитывается по формуле 6:

, (6)

где B[t] - выгоды проекта за месяц t;

C[t] - издержки проекта за месяц t;

I - ставка дисконтирования (ставка рефинансирования + величина рисков, %).

Коэффициент рентабельности инвестиций характеризует доходность инвестиционных вложений рассчитывается по формуле 7:

, (7)

где Прибыль - доходы, полученные за время владения ИТ-активом;

Цена приобретения - цена, по которой был приобретен ИТ-актив;

Цена продажи - цена, по которой был продан (или может быть продан) ИТ-актив по окончании срока владения.

Приложение 3. Оценка длительности проекта средствами симулятора Riscology

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

В симуляторе задаются риски: непрерывные (задаются непрерывной функцией распределения) и бинарные (задаются дискретно, вероятностью их возникновения). Бинарные риски также подразделяются на фатальные и нефатальные. Бинарные риски можно использовать для моделирования катастроф. Они свидетельствуют о необходимости искать новые пути реализации проекта или отказа от проекта. Непрерывные риски моделируются треугольным распределением (см. рисунок 21).

Рисунок 21. График треугольного распределения вероятности проявления риска ограниченного доступа к инструментам разработки

Все выбранные риски рассматриваются как причинные риски. Причинные риски приводят к агрегированному риску. На выходе симулятор строит гистограмму совокупного риска.

Получив распределение совокупного риска возможно решение двух задач:

ѕ с какой вероятностью длина критического пути (срок выполнения проекта) не будет превышать конкретное значение Т*;

ѕ какой срок необходимо заложить на выполнение проекта, чтобы уложиться в него с заданной вероятностью.

В основе концепции расчета длительности проекта в симуляторе Riscology лежит метод статистических испытаний (или метод Монте-Карло).

Целью оценки длительности проекта по разработке программного обеспечения «СКЦ Росатома» является расчет вероятности наступления форс-мажорного завершения проекта и определение «Выполнится ли проект в течении полутора лет».

Основные характеристики проекта «СКЦ Росатома»:

Дата начала проекта - 10.14 (месяц, год соответственно).

Нанопроцентная дата завершения - 10.15 (месяц, год соответственно).

Таким образом, заданы временный характеристики хода проекта - СКЦ Росатома имеет длительность, равную одному году.

Описание рисков проекта «СКЦ Ростаома»:

ѕ изъяны календарного планирования (RF1);

ѕ текучесть кадров (RF2);

ѕ раздувание требований (RF3);

ѕ нарушение спецификаций (RF4);

ѕ низкая производительность (RF5);

ѕ низкая квалификация работников (RF6);

ѕ ограниченный доступ к инструментам разработки (RF7).

В зависимости от того, является риск бинарным или непрерывным, в Riscology производится настройка параметров (см. таблицу 9).

Таблица 9. Настройка параметров рисков в Riscology

Для непрерывных рисков	Для бинарных рисков
Наихудшее значение задержки, например, 50% (определяет положение правой вершины треугольника)	Вероятность риска
Наиболее вероятное значение задержки, например, 20% (определяет положение верхней вершины треугольника)	Отметка фатальности риска
Наилучшее значение задержки, например, 0% (определяет положение левой вершины треугольника)

Подобные документы

• Реализация сервис-ориентированной архитектуры

  Поисковые системы. Описание и сравнение сервисов поисковых систем, предоставляемых пользователям. Сравнительный анализ интерфейсов. Риски использования поисковых систем. Блокировка вирусных сайтов. Загруженность главной страницы новостями и рекламой.
  
  презентация [198,3 K], добавлен 17.01.2014
  

• Использование сетевых технологий при проектировании дистанционной информационной системы и компьютерной сети

  Понятие и общая характеристика дистанционных информационных систем, их основные функции и задачи. Разработка ДИС для IT-компании Envisionext и проектирование компьютерной системы, объединяющей 20 рабочих станций. Обзор сайтов конкурентов данной компании.
  
  курсовая работа [1,8 M], добавлен 24.09.2012
  

• Проектирование информационной системы компании "IT-Сервис"

  Наличие экономической информационной системы. Матрица организационных проекций. Разработка системы базы данных. Современные CASE-средства. Основные этапы разработки информационных систем. Абсолютный показатель и индекс снижения стоимостных затрат.
  
  курсовая работа [1,1 M], добавлен 14.03.2011
  

• Хранилища данных

  Концепции хранилищ данных для анализа и их составляющие: интеграции и согласования данных из различных источников, разделения наборов данных для систем обработки транзакций и поддержки принятия решений. Архитектура баз для хранилищ и витрины данных.
  
  реферат [1,3 M], добавлен 25.03.2013
  

• Информационные системы

  Описание информационных систем, применяемых на российских предприятиях для ведения бухгалтерского учета. Информационные системы для анализа финансово-хозяйственной деятельности. Описание корпоративной информационной системы на примере системы ГАЛАКТИКА.
  
  отчет по практике [395,8 K], добавлен 27.12.2010
  

• Блочно-симметричные модели и методы проектирования систем обработки данных

  Обзор моделей анализа и синтеза модульных систем обработки данных. Модели и методы решения задач дискретного программирования при проектировании. Декомпозиция прикладных задач и документов систем обработки данных на этапе технического проектирования.
  
  диссертация [423,1 K], добавлен 07.12.2010
  

• Особенности внедрения корпоративных информационных систем

  Изучение понятия корпоративной информационной системы; требования к их разработке. Ознакомление с процессом проектирования и внедрения данных компьютерных технологий на производстве. Рассмотрение специфики работы корпоративных информационных систем.
  
  курсовая работа [33,1 K], добавлен 02.11.2014
  

• Разработка информационной системы бухгалтерского учета для автоматизации рабочего места оператора телефонной компании по предоставлении услуг

  Проектирование информационных систем. Разработка информационной системы в 1С. Создание справочников и документов, регистров накопления и регистров сведений. Пропускная способность системы. Автоматизация рабочего места оператора телефонной компании.
  
  курсовая работа [1,6 M], добавлен 29.07.2013
  

• Интеграция информационных систем предприятия

  Рассмотрение взаимосвязи информационных подсистем предприятия. Характеристика сервис-ориентированной архитектуры информационных систем. Оценка реализации SOA-инфраструктуры на базе сервисной шины предприятия. Анализ бизнес-цели внедрения SOA-решений.
  
  контрольная работа [1,0 M], добавлен 28.03.2018
  

• Изучение и описание живой и неживой системы с точки зрения классификации информационных систем

  Классификация систем: по отношению системы к окружающей среде, по описанию переменных систем, по типу описания законов функционирования системы, по способу управления. Примеры описания живой и неживой системы с точки зрения информационной системы.
  
  доклад [16,2 K], добавлен 02.06.2010
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам