Вход

Внедрение инструмента бизнес аналитики для процесса планирования уровня запасов, а также спроса и продаж в организации здравоохранения на базе Infor

Дипломная работа*
Код 386752
Дата создания 2017
Страниц 71
Файлы будут доступны для скачивания после проверки оплаты.
Мы онлайн и готовы обработать ваш заказ.
2 740руб.
КУПИТЬ

Описание

Дипломная работа включает в себя: много рисунков, таблиц, схем.

Тема: «Внедрение инструмента бизнес аналитики для процесса планирования уровня запасов, а также спроса и продаж в организации здравоохранения на базе Infor ION BI»

Введение - 3 страницы;
Список литературы - 12 источников;
Заключение - 2 страницы;
А также приложение в конце работы. ...

Содержание

Оглавление

Введение 4
Глава 1. Постановка проблемы и первичные изыскания 7
1.1 Процесс планирования: описание, критичность и влияние на бизнес 7
1.2 Возможности автоматизации процесса 14
1.3 Предварительные оценки экономической эффективности, постановка целей 17
1.4 Анализ основных программных комплексов Бизнес Аналитики 21
Глава 2. Проектирование компонентов системы 28
2.1 Окружения: среда разработки, тестирования и рабочая 28
2.2 Интерфейсы и взаимодействие с внешними системами 33
2.3 Хранилище данных 43
2.4 OLAP и отчетность 48
Глава 3. Этап завершения проекта 57
3.1 Выстраивание процедуры внесения и переноса изменений 57
3.2 Планирование запуска системы 61
3.3 Оценка изменений бизнес-процесса, экономическая выгода 65
Заключение 69
Список используемой литературы 71
Приложения 72

Введение

Введение

В рамках данной выпускной квалификационной работы, рассмотрим проект внедрения инструмента бизнес-аналитики в Российском филиале международной фармацевтической компании Abbott Laboratories, поддерживающий один из сегментов процесса управления запасами в цепях поставок, а в частности - процесс планирования запасов.
Актуальность темы заключается в том, что в настоящий момент, Российский фармацевтический рынок, является все еще высоко-привлекательным, с цифрами роста более 10% в год [10]. При подобных темпах роста, рынок привлекает огромное количество как внутренних, так и внешних инвестиций и как следствие - формируются жесткие условия конкуренции.
Не смотря на то, что в 1995 году в книге «The Discipline of Market Leaders» [1], авторами было сформировано утверждение, что фирма м ожет быть успешной, придерживаясь одной из выбранных стратегий (Customer Intimacy, Product Leadership, Operational Excellence), для любых фармацевтических компаний, желающих успешно работать в условиях высоко-конкурентной среды развивающегося рынка, совершенно необходимым условием являются конкурентные преимущества в дисциплине Operational Excellence – связанной с оптимизацией издержек и снижением себестоимости.
Одним из основных пунктов оптимизации в данной дисциплине, особенно для тех организаций, чей основной бизнес является продажа и производство дорогостоящей продукции, с ограниченным сроком годности – является оптимизация цепей поставок, и как более низкий декомпозированный уровень – умение эффективно управлять уровнем запаса продукции на складах организации, компаний-партнеров.
Дополнительную актуальность придает тот факт, что именно этот бизнес-процесс получает, наибольшие выгоды от использования информационных технологий, ввиду его специфики: большого числа информационных источников; огромных объемов данных; значительных математических вычислений, а также – низкого уровня предметной подготовки участников процесса (в данном примере системные вычисления, автоматизированные построения графиков и «приборных панелей» компенсирует слабое понимание предмета участниками).
Таким образом, объектом исследования данной выпускной квалификационной работы является бизнес-процесс планирования уровня запасов, а соответственно величин спроса и продаж.
Предметом исследования выступает проект автоматизации, призванный оптимизировать основные показатели данного процесса - проект внедрения инструмента, не просто поддерживающего данный процесс, но и обеспечивающий своеобразный архитектурный ландшафт, для всех околопроцессных активностей.
Цель выпускной квалификационной работы – разработать инструмент бизнес аналитики, поддерживающий процесс планирования запасов.
Для достижения данной цели необходимо решить следующие задачи:
• проанализировать автоматизацию процесса планирования запасов;
• провести расчет предварительной оценки экономической эффективности разрабатываемого проекта;
• провести анализ основных программных комплексов Бизнес Аналитики;
• спроектировать компоненты системы;
• разработать проект системы бизнес аналитики;
• провести расчет оценки изменений бизнес-процесса.
Практическая значимость данной работы заключается в:
• снижении фактических трудозатрат владельцами и участниками бизнес-процесса, путем автоматизации рутинных процессов сбора информации из множественных источников;
• предоставляет новые возможности для отделов развития бизнеса – анализ корреляций поведения рынка, рыночных групп, фокусных рынков продуктов;
• облегчает принятие менеджерских решений, путем внедрения преднастроенных «приборных панелей», показывающих уровень того или иного показателя;
• предоставляет гибкую платформу, унифицирующую результаты деятельности процесса планирования, и делающую её подходящей для использования в последующих бизнес-процессах компании, например, процесс финансового планирования, управления поставщиками и пр.

Фрагмент работы для ознакомления

Теперь, когда были сформированы требования к, так называемой «боевой среде» необходимо понять общее количество требуемых ресурсов. Для этого, нужно необходимо обозначить, сколько и какие среды созданы за время проекта.Наиболее полно, процесс разработки программного обеспечения или интеграционные проекты по гибким методологиям ведения проектов для решений корпоративного класса, описаны в книге «Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise» [7]. На рисунке 6, приведена схема самих сред разработки, их взаимодействия и степень контроля и защищенности.Рисунок SEQ Рисунок \* ARABIC 6 - Схематичное изображение средDevelopment Sandbox – или среда разработки – окружение, которое создается поставщиком (в данном случае – компанией внедряющей проект), на своих мощностях. Он полностью несет ответственность за техническое сопровождение данной среды. Это непосредственное место разработки и основное место первоначального модульного тестирования для разработчика. Все проблемы и ошибки исправляются непосредственно разработчиком по мере возникновения.Project Integration Sandbox (в терминологии организации, это DEV среда) – или среда проекта, как правило – это отдельная среда, на которой происходит первоначальная выкладка всех вносимых изменений в разработку и происходит первоначальное тестирование заказчиком, в том числе и интеграционное тестирование. Эта среда обладает слабым уровнем защищенности, то есть и разработчик, и любые участники проекта имеют высокие права и возможности вносить изменения. Так же характеризуется редкими обновлениями - то есть зачастую на ней наиболее устаревшая информация по сравнению с «боевой» (рабочей) средой. Все ошибки разработки (баги) сообщаются разработчику и исправляются на данной среде, путем непосредственного исправления кода или выпуска пакета изменений.Далее, описываются две среды, которые во многих случаях объединяют в одну, как и было сделано во время исполнения проекта, описанного в выпускной квалификационной работе – Demo Sandbox и Test/QA Sandbox. Эти среды предназначены для проведения интеграционного, а также системного (end-to-end) тестирования. Они характеризуются высоким уровнем контроля – разработчик, как правило, не имеет доступа на данную среду и все изменения переносятся силами заказчика, поддерживающими данное приложение. Именно на этой среде происходит приемочное тестирование пользователями, после чего подписывается документ о приемке или не приемке системы. Все факты тестирования на этой среде должны быть формализованы и запротоколированы, для предоставления далее в отдел качества организации. Все исправления или найденные огрехи разработки, исправляются с помощью пакетов изменений.Production – рабочая, «боевая среда», на которой работают пользователи готового продукта. Она характеризуется самым высоким уровнем контроля и защиты. К этой среде уже нет доступа как у поставщика, так и у команды проекта. Весь процесс переноса изменений происходит через работников, осуществляющих непосредственное функционирование системы. Все исправления или найденные огрехи разработки, исправляются с помощью пакетов изменений, предварительно прошедших успешное системное и пользовательское тестирование на Test/QA Sandbox среде.Полная информация по средам сведена на едином рисунке 7 для большей наглядности.Рисунок SEQ Рисунок \* ARABIC 7 – Схематичное изображение сред и серверовНа рисунке 7 серверы разделены на Database Servers, которые приведены в левом столбце и серверы приложений (Application Servers) или BI Servers. Данная схема позволяет понимать полную величину необходимых ресурсов, для корректного поддержания всех сред. Следует отметить, что среда разработчиков не обозначена на данной схеме ввиду описанного выше принципа, что она находится в зоне ответственности подрядчика.2.2 Интерфейсы и взаимодействие с внешними системамиВ бизнес-процессе были выделены, как входящие, так и исходящие интерфейсы. При этом, список входящих интерфейсов состоит из интерфейсов: Продукции, Цен, факт первичных продаж (Sales To Market), факт вторичных продаж (Sales In market), факт текущего стока компании (Stock To Market), прогноза поставок (Replenishment), прогноза вторичных продаж канала дополнительного и льготного обеспечения (продажи ДЛО), а также фактический запас товара в рынке (Fact Stock in Market). Список исходящих интерфейсов состоит из всего двух сущностей: прогноз продаж для выгрузки в систему планирования заказов у поставщиков «SAP»; и выгрузки финансовой отчетности в систему корпоративного финансового планирования «Hyperion».Для формализации процесса, за каждым интерфейсом закреплен его владелец, ответственный за предоставление и/или проверку данных в источнике.Прежде чем, перейти к рассмотрению интерфейсов, необходимо четко понимать из чего состоят информационные потоки, которые стоят за ними.Потому что, если в случае интерфейса продуктов, информационный поток достаточно ясен – это карточка продукта, и минимальный набор атрибутов, необходимый для построения отчетности, то в случае других интерфейсов, таких как факт вторичных продаж модель данных может быть сложнее.Продукты - это интерфейс, с достаточно простой моделью данных, где фиксируются уникальные коды из нескольких учетных систем, для возможности работы последующих интерфейсов. Схематично, структура данных изображена на рисунке 8, где уровень SKU (Stock Keeping Unit – складская позиция) является определяющим уровнем, на котором хранится вся информация об отгрузках, уровня запаса и производятся все расчеты. Рисунок SEQ Рисунок \* ARABIC 8 - Соотношение записей позицийЛогически, данный уровень называть SKU некорректно, так как уровни SAP APO Material ID (код материала запаса из системы планирования заказов) и SAP Grade Material ID (код материала запаса из системы планирования ресурсов предприятия) фактически являются тем, что общепринято называть Stock Keeping Unit. Но так как, в организации именно уровень дозировки и формы выпуска препарата, принято называть SKU то, было решено использовать терминологию, уже устоявшуюся в процессе.Детальное описание всех полей интерфейса заняло достаточно продолжительное время, а их смысловая нагрузка невелика, поэтому они приведены все списком, с указанием типа поля и пример информации.В таблице 6 указаны атрибуты интерфейса продукции компании.Следующий важный интерфейс, необходимый для пересчета дальнейших интерфейсов – цены.В таблице №7 описан интерфейс цены, который является основным интерфейсом, вместе с интерфейсом продукции, так как именно на базе значений из этих двух интерфейсов происходит дальнейший пересчет значений остальных интерфейсов.Таблица SEQ Таблица \* ARABIC 6 – Продукты компании с базовыми атрибутамиИмя поляТипПримерBUTextBusiness Unit for OTC ProductsTATextOTC – ImmunologyBrandTextSample BrandSubBrandTextSample SubBrandSKU NameTextSample Brand 16 mgSKU codeText1234567890SKU DescriptionTextSample Brand 16 mgSAP GRADE codeInteger10169162SAP APO codeInteger1087242SAP APO NameTextSample Brand 16mg 2x15tab RUSAP Grade NameTextSample Brand 16mg 2x15ta1-6-3-3-3 codeText1-XXXXXX-105-S10-7511-6-3-3-4 codeText1- XXXXXX -105-S10-0751D56 codeText100XXXXXX0S10751WBS codeTextWBS100XXXXXX0S10751Active toDate10.11.2015Cognos Product GroupsTextSMBRANDBullseye Product GroupTextPS150Finance Product GroupsTextS150 BRNDAX/DXTextAXCEU FactorNumber0,00048EDLBooleanTRUE/FALSEOTCBooleanTRUE/FALSEManufacturer Release (Supplier)TextXXX Healthcare SAS, FranceSupplier country TextFRShelf LifeInteger60EntityTextE1091Таблица SEQ Таблица \* ARABIC 7 – Список полей интерфейса «цены»Имя поляТипПримерDateDate01.01.2015BrandTextSample BrandSKU NameTextSample Brand 16 mgSKU code Text1234567890Price typeTextPlanChannelTextTotalCurrencyTextRUBPrice valueNumber150,50Где поле «Price type» - это тип цены, которая может быть: Плановая – прогноз, зафиксированный с головным представительством компании; фактическая – за прошедшие периоды; прогнозная – расчетная цена на будущие периоды.После описания базовых интерфейсов, которые, практически являются мастер-данными, можно перейти к часто изменяемым данным - продукция и цены, в таблице 8.Таблица SEQ Таблица \* ARABIC 8 – Поля интерфейса «Вторичные продажи»Имя поляТипПримерSKU Name TextSample Brand 16 mgSKU codeText1234567890DateDate01.01.2015ChannelTextRetailQuantityNumber29800CurrencyTextRUB, EUR, USDAmountNumber1000000,00Где Channel (канал), это соответствующий сегмент рынка, а поле Date (дата) – это любое число месяца, в который будет засчитана данная продажа.В таблице 9 приведены поля интерфейса первичные отгрузки.Таблица SEQ Таблица \* ARABIC 9 – Поля интерфейса «первичные отгрузки»Имя поляТипПример*SAP GRADE codeInteger10144958DateDate01.01.2015QuantityNumber29941CurrencyTextRUB, EUR, USDAmountNumber1000000,00Net AmountNumber100000,00Где Amount – это сумма отгрузок без учета скидок, а Net Amount – сумма отгрузок с учетом всех скидок и начислений прямым клиентам компании.Следует заметить, что разделения первичных отгрузок по каналам на этапе внедрения проекта не происходило – так как первоначально, компания не всегда может знать, отгружает ли она ту или иную партию товара дистрибьютору для розничных продаж (аптеки) или для любого другого канала рынка. Date (дата), как и в случае вторичных отгрузок важен месяц отгрузки.В таблице 10 - поле Stock (запас) – это уровень запасов той или иной складской позиции, а Available Stock (доступный запас) – уровень доступной продукции, которая не была зарезервирована под ближайшие отгрузки.Таблица SEQ Таблица \* ARABIC 10 – Поля интерфейса Фактический запас продукцииИмя поляТипПримерSKU NameTextSample Brand 16 mgSAP GRADE codeInteger10144958DateDate01.01.2015StockNumber29941Available StockNumber29800Для загрузки прогноза поступления продукции, будет использоваться интерфейс с полями, описанными в таблице 11.Таблица SEQ Таблица \* ARABIC 11 – Поля интерфейса прогноза поступления продукцииИмя поляТипПримерReplenishment phaseTextRMRP Replenishment PlanSAP APO codeInteger10144958DateDate01.01.2015QuantityNumber15050Прогноз продаж по каналу ДЛО (Дополнительное льготное обеспечение) очень похож на предыдущий интерфейс и описан в таблице 12.Таблица SEQ Таблица \* ARABIC 12 – Поля интерфейса «Прогноз по каналу ДЛО»Имя поляТипПримерSKU NameTextSample Brand 16 mgSAP Grade codeInteger10144958DateDate01.01.2015QuantityNumber29941Так как в рамки проекта входит построение отчетности, которая будет отправляться в головной офис компании, существует необходимость переводить все цифры рублевых продаж в долларовые, по определенным курсам (в зависимости от типа отчета). Для этого разрабатывается интерфейс Обменный курс, описанный в таблице 13.Таблица SEQ Таблица \* ARABIC 13 – Поля интерфейса «Обменный курс»Имя поляТипПримерDateDate01.01.2015ExchangeTypeTextPlan, BookRate, ActualsCurrencyTextRUB, EUR, USDRate Number50,05Где под типом обменного курса (Exchange Type) подразумевается различные типы курсов, для формирования отчетности: плановые показатели курсов – прогноз, который был зафиксирован с головным представительством компании, фактический и прогнозный курс.Так как запасы продукта в рынке, это расчетная величина, формирующаяся из продаж в рынок (Sales To Market) и продаж в рынке (Sales In Market), то существует большая вероятность накопления погрешности, при не всегда корректных данных вторичных продаж. Для этого, необходимо иметь возможность сверяться с дистрибьюторами и загружать их выверенные запасы, для этого разработан интерфейс, описанный в таблице 14.Таблица SEQ Таблица \* ARABIC 14 – Поля интерфейса фактические запасы продукта в рынкеИмя поляТипПримерSKU NameTextSample Brand 16 mgSKU codeInteger1234567890DateDate01.01.2015StockNumber12345Так как процесс управления запасами, является лишь одним из звеньев всей цепочки поставок, то у этого процесса есть как входные, так и выходные данные. Этот процесс, на выходе формирует прогнозируемые количества, которые должны быть поставлены на склад компании, для поддержания корректного уровня запасов. Этот прогноз может быть использован заводами компании, для составления производственного расписания. Интерфейс, обеспечивающий выгрузку данных прогноза продаж, на основании которых формируется план поставок, описан в таблице 15.Таблица SEQ Таблица \* ARABIC 15 – Поля интерфейса-выгрузки прогноза продажИмя поляТипПримерForecast typeConstant«Base Forecast»SAP APO codeText00204910UnitConstant«PC, RUB»Current monthTextM 06.2014Month 1TextM 07.2014………Month 28TextM 11.2016Второй выходной интерфейс, который обеспечивает выгрузку результатов планирования в финансовую систему описан в таблице 16.Таблица SEQ Таблица \* ARABIC 16 – Поля интерфейса-выгрузки в HyperionИмя поляТипПримерAccountConstant«FXXX_Inp»EntityConstant«E5012»Performance UnitConstant«10983»Transactional Currency CodeTextRUBFunctionConstant«F-SALESOTHERS»WBSTextWBS100XXXXXX0S10751*Jan-20ххTextПервый месяц текущего года…Text…*Dec-20ххTextПоследний месяц текущего годаПосле того, как детально описаны все интерфейсы, представляется возможным приступить к представлению концепции – как будет происходить сам ETL процесс. На рисунке 9 приведено схематичное изображение системы. Где процесс ETL разбит на несколько этапов:Рисунок SEQ Рисунок \* ARABIC 9 – Общая схема системыETL 1 – Выгрузка из системы источника происходит различными инструментами, доступными для данных систем и остается за рамками проекта.На этапе ETL 2 происходит проверка приведение информации в вид, соответствующий описанным выше спецификациям по каждому интерфейсу.ETL 3, 4 - происходит перенос и загрузка сырых данных в реляционную базу данных.ETL 5 - Выверка данных. Во время этого шага, загруженные данные проверяются на уникальность, соответствие типовым словарным значениям, если такие существуютETL 6 – этап трансформации данных, во время которого происходит нормализация, в случае необходимости обогащение и приведение данных в формат, подходящий для дальнейшей загрузки в OLAPETL7 – наполнение кубов OLAP данными хранилища.ETL процесс образовывается несколькими системами. Весь обмен данными между хранилищем и системами-источниками данных происходит путем обмена CSV (Comma Separated Values) файлами. Так как выгрузка из этих систем-источников, остается за рамками проекта, то они не рассматриваются в рамках данной выпускной квалификационной работы. Таким образом, полученный csv файл размещается в специальной сетевой папке, отдельной для каждого интерфейса.Подробнее остановимся на этой части проекта, так как, не смотря на свою примитивность, она обеспечивает базовое разграничение прав доступа, а также вносит структурированность и облегчает поиск ошибок.В папке каждого интерфейса, созданы три под-папки:CURR (от английского current) – в эту директорию поступают файлы от систем-источников информации и находятся там до тех пор, пока не наступит ETL3 процесс – то есть, пока не будет запущен исполняемый файл входящего интерфейса системы.ERR (от английского error) – в данную папку помещаются файлы, при импорте которых были найдены ошибки как на этапе ETL4 – базовые ошибки в названии или структуре файла (неверное количество столбцов), так и на этапе ETL5 –проверке данных, например неверные коды продуктов или некорректные названия канала продаж. С каждым ошибочным файлом формируется так же служебный файл, описывающий ошибки, которые были найдены во время импорта.HIST (от английского history) – помещаются все файлы, успешно прошедшие этапы ETL4,5 и чьи данные были помещены в хранилище.Директория каждого интерфейса расположена в соответствующей директории типов интерфейсов – IN (входящие интерфейсы) и OUT (исходящие интерфейсы). А в свою очередь директории типов интерфейсов, расположены в релевантных папках, описанных выше сред (Prod, UAT, DEV).Учитывая, что в данных интерфейсах передается важная информация для компании, отпускные и прогнозные цены, количество состоявшихся отгрузок, запланированных загрузок и прочее, необходимо разграничивать доступ, как на изменение, так и на просмотр данной информации. Так как эти директории расположены в сетевом доступе, то для управления доступом используются доменные группы – то есть, для каждого интерфейса обозначены их владельцы, под каждый интерфейс создана своя группа и в неё включены владельцы интерфейсов.Соглашение о названии групп, формируется из следующих элементов:«RU_» - обязательный префикс для всех российских групп организации«KPL» - трехбуквенная аббревиатура системы (в организации данному проекту присвоено название «Kepler»)«PRD» - трехбуквенная аббревиатура среды системы (DEV, UAT, PRD)«название интерфейса» - английское название интерфейса.Схематично права доступа представлены в таблице 17. Для упрощения будет рассмотрена только одна среда, для всех остальных сред полномочия распределяются аналогично.Таблица SEQ Таблица \* ARABIC 17 – Схематичное представление директорий интерфейсов и правТипИнтерфейсСостояниеНаследованиеГруппаINXDLO ForecastRU_KPL_PRD_DLOCURRXERRXHISTXPriceRU_KPL_PRD_PRICECURRXERRXHISTX…OUTXHyperionPlanRU_KPL_PRD_HyperionRU_KPL_PRDCURRXERRXHISTX…Все базовые файловые операции (перемещение, чтение, загрузка), для увеличения скорости и гибкости разработки выполняются с помощью исполняемых файлов, написанных на Visual Basic. Все операции выверки данных (шаги ETL4, 5), а также трансформации данных (ETL6) производятся средствами SQL.2.3 Хранилище данныхДостаточно полное определение дано в книге «Использование MS SQL Server Analysis Services 2008 для построения хранилищ данных» [12]. Хранилище данных – это «предметно-ориентированный, интегрированный, редко меняющийся, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений».В рамках проекта, рассматриваемого в выпускной квалификационной работе, создано хранилище данных, которое ориентировано на поддержание принятие решений по процессу управления уровнем запасов организации. В данном разделе работы, будет рассмотрена его часть, выполненная в реляционных таблицах (SQL Server), являющихся частью ETL процесса (интерфейсные таблицы), а также таблицы, являющиеся служебными, расчетными, словарями метаданных.Для каждого интерфейса, в системе созданы интерфейсные таблицы (рисунок 10).Для таблиц введено простейшее соглашение об именах:«Имя Интерфейса» + «IntTable» – это таблица, в которую происходит загрузка данных (методом SQL, bulk insert). Таким образом, в неё попадают все данные, прошедшие фазу ETL4 – с правильными именами файлов и верной структурой данных файла.«Имя Интерфейса» + «BufTable» - таблица, в которую после успешной загрузки и первичной проверки типов данных (число, дата, текст) перенесли информацию. Эта таблица используется шага ETL5, во время которого происходит сверка значений полей, со словарем метаданных. Для тех записей, для которых это необходимо проводится шестой этап процесса ETL.Рисунок SEQ Рисунок \* ARABIC 10 – Интерфейсные таблицы «Имя Интерфейса» - основная таблица, содержащая все исторические данные, которая используется для хранения информации и в дальнейшем для наполнения кубов OLAP. В неё переходят только записи, прошедшие этапы ETL4,5.Расчетные таблицы – таблицы, предназначенные для сложных расчетов, которые по своей природе проще производить в реляционной среде, чем в OLAP, такие как пересчет кросс-курсов, расчет средних цен или расчет уровня запасов в рынке (StockInMarket).Служебные – таблицы, необходимые для хранения базовых настроек текущего состояния системы, такие, как таблицы версий, циклов, рабочего календаря. И таблицы текущего состояние процесса, а также таблицы аудита – фиксирующие критичные для бизнес-процесса действия его участников.В рамках проекта, было написано более 30 хранимых SQL процедур (рисунок 11), отвечающих за выверку, перемещение, обогащение информации, которое происходит в интерфейсных таблицах, а также за вычисления, производимые в расчетных таблицах.

Список литературы

Список используемой литературы

1. Дыбская В.В. [и др.] Логистика. Интеграция и оптимизация логистических бизнес-процессов в цепях поставок. – М.: ЭКСМО, 2011.
2. Исследование рынка труда и обзор зарплат 2013- 2014г. [Отчет]. – М.: Antal Russia, 2014.
3. Полубояров В.В. Использование MS SQL Server 2008 Analysis Services для построения хранилищ данных. ННТУ, 2010.
4. Родников А. Н. Логистика. Терминологический словарь. 2-е издание. – М.: Инфра-М, 2000.
5. Infor Hardware Recommendations Guide. - [б.м.] : Infor ION BI, 2014 г.
6. Lines Mark и Ambler Scott W. Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise [Книга]. - [б.м.] : IBM Press, 2012.
7. Treacy Michael и Wiersema Fred The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market: Addison-Wesley, 1995.
8. http://fortune.com/fortune500/ [В Интернете] // Fortune. - 2014 г.. - 2014 г.
9. IMS Health MS Market Prognosis - Russia [Report]. - 2013.
10. IMS Health IMS Market Prognosis 2014-2018, Russia [В Интернете] // http://www.imshealth.com. - IMS Health, September. 2014 г.
11. Ross Margy The Bottom-Up Misnomer [В Интернете] // kimballgroup. - kimballgroup, 17 SEP 2003 г. - 2014 г. - http://www.kimballgroup.com/2003/09/the-bottom-up-misnomer/.
12. Sallam Rita L. [и др.] Magic Quadrant for Business Intelligence and Analytics Platforms [В Интернете] // gartner.com. – 02. 2014 г.
Пожалуйста, внимательно изучайте содержание и фрагменты работы. Деньги за приобретённые готовые работы по причине несоответствия данной работы вашим требованиям или её уникальности не возвращаются.
* Категория работы носит оценочный характер в соответствии с качественными и количественными параметрами предоставляемого материала, который не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, но может использоваться в качестве источника для подготовки работы указанной тематики.
© Рефератбанк, 2002 - 2019