ДИПЛОМНАЯ РАБОТА НА ТЕМУ: «ИНТЕГРАЦИЯ «SIKE. AUTOPARK» И «КАСУН» НА ПРЕДПРИЯТИИ ООО «ГАЗПРОМ ТРАНСГАЗ ТОМСК» - Студенческий научный форум

VII Международная студенческая научная конференция Студенческий научный форум - 2015

ДИПЛОМНАЯ РАБОТА НА ТЕМУ: «ИНТЕГРАЦИЯ «SIKE. AUTOPARK» И «КАСУН» НА ПРЕДПРИЯТИИ ООО «ГАЗПРОМ ТРАНСГАЗ ТОМСК»

Грецу Р.М. 1, Новикова Т.Б. 1
1МАГНИТОГОРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ИМ. Г.И. НОСОВА
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

Введение

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

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

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

Таким образом, руководством предприятия ООО «Газпром трансгаз Томск» было принято решение автоматизировать передачу данных о заправках в путевые листы. Данное решение позволит сократить время обработки путевых листов и исключит в них несоответствия по заправкам с данными системы КАСУН. Решение будет реализовано посредством организации обмена данными между ИУС «SIKE.Autopark» и «КАСУН».

Объектом исследования является деятельность предприятия ООО «Газпромтрансгаз Томск», которое занимается добычей, транспортировкой и реализацией природного газа.

Предметом исследования является интеграция ИУС «SIKE.Autopark» и «КАСУН» на предприятии ООО «Газпромтрансгаз Томск».

Целью дипломной работы является разработка и реализация проекта интеграции ИУС «SIKE.Autopark» и «КАСУН» на предприятии ООО «Газпромтрансгаз Томск» для эффективного управления информацией по заправочным станциям, о фактах заправки и обработкой данных на филиалах.

Были определены следующие задачи:

  1. Проведение предпроектного обследования ООО «ГАЗПРОМ ТРАНСГАЗ ТОМСК».

  1. Проведение анализа технических требований по интеграции «SIKE.Autopark» и «КАСУН».

  2. Выявление «узких» мест и принятие управленческого решения.

  3. Разработка общей схемы потоков данных между «SIKE.Autopark» и «КАСУН».

  4. Разработка блок-схем алгоритмов передачи данных «SIKE.Autopark» - «КАСУН».

  5. Разработка частных технических заданий на алгоритмы передачи о фактах заправок, о заправочных станциях, данных из центра интеграции в ИУС «SIKE.Autopark», а так же частное техническое задание на алгоритм передачи данных из центральной базы компании в филиалы.

  6. Реализация проектных решений по интеграции «SIKE.Autopark» и «КАСУН».

  7. Обоснование экономической эффективности интеграции систем.

Средствами анализа являлись методология ARIS (CauseandEffectDiagram – «Диаграмма Исикавы», OrganizationChartDiagram – организационная диаграмма, eEPC – функциональная диаграмма) и методология объектного анализа и проектирования (RUP) (UseCaseDiagramm – диаграмма вариантов использования).

Практическая значимость ВКР состоит в разработке и реализации проекта интеграции ИУС «SIKE.Autopark» и «КАСУН» на предприятии ООО «Газпром трансгаз Томск».

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

Участие в международной научно практической конференции «Молодежь. Наука. Инновации», посвященной 300-летию со дня рождения М.В. Ломоносова. Город Пенза.

Статья: Давлеткиреева Л.З., Грецу Р.М. Автоматизация учета путевых листов на газодобывающем предприятии посредством интеграции ИУС «SIKE.Autopark» и системы КАСУН.

На защиту выносится:

  1. Частное техническое задание на алгоритм передачи данных о заправочных станциях»;

  2. Частное техническое задание на алгоритм обработки данных на филиалах»;

  3. Частное техническое задание на алгоритм передачи данных о фактах заправки»;

  4. реализованный проект интеграции ИУС «SIKE.Autopark» и «КАСУН» на предприятии ООО «Газпромтрансгаз Томск»ГЛАВА 1 АНАЛИТИЧЕСКАЯ ЧАСТЬ

  1.  
    1. Технико-экономическая характеристика предметной области

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

Газовая отрасль играет стратегическую роль в экономике России. На долю газа приходится около половины общего объема производства и внутреннего потребления энергетических ресурсов. В настоящее время в России доля газа в топливном балансе ТЭС составляет 62%, а в европейской части - 86%. Отрасль обеспечивает порядка 10% национального ВВП, до 25% доходов государственного бюджета страны. Экспорт природного газа приносит России около 15% валютной выручки. Обладая крупнейшими в мире запасами природного газа (47,82 трлн куб. м) и не имея равных по объемам годовой добычи (656 млрд куб. м в 2006 году), Россия является важнейшим звеном мировой газовой промышленности. В структуре общемирового экспорта газа на долю России приходится свыше четверти всего объема. Добыча газа за январь-февраль 2008 года составила 118,44 млрд. куб. м (102,4% к январю-февралю 2007 г.). Характерной особенностью отрасли является серьезное доминирование в ней «Газпрома».

Факторы среды предприятия

Из диаграммы видно, что газ занимает прочное место в ТЭКе России. Добыча газа превышает добычу других видов топливных ресурсов. Благодаря обширным запасам, конкурентоспособным ценам и экологическим преимуществам, добыча и потребление природного газа будут расти опережающими темпами по сравнению с другими первичными энергоносителями (таблица 1).

Таблица 1. Сравнение использования газа с другими энергонасителями

 

1940

1950

1960

1970

1980

1990

2002

Нефть

18,7

17,4

30,5

41,1

45,3

39,7

35

Газ

1,9

2,3

7,9

19,1

27,1

40

50

Уголь

59,1

66,1

53,9

35,4

25,4

18,1

12

Другое

20,3

14,2

7,7

4,4

2,2

2,5

3

Основные газопроводные системы России

Газопровод — инженерное сооружение, предназначенное для транспортировки газа с помощью трубопровода.

Российские магистральные газопроводы: Уренгой — Помары — Ужгород; Ямал — Европа; Голубой поток; Северный поток; Южный поток; Алтай; Сахалин-Хабаровск-Владивосток. «Голубой поток» — газопровод между Россией и Турцией, проложенный по дну Чёрного моря.

Общая протяжённость газопровода — 1213 км, из них: сухопутный участок на российской стороне от города Изобильный Ставропольского края до села Архипо-Осиповка Краснодарского края на побережье Черного моря длиной 373 км; морской участок от Архипо-Осиповки до терминала «Дурусу», расположенного в 60 км от города Самсун (Турция) длиной 396 км; сухопутный участок на турецкой стороне от города Самсун до города Анкара длиной 444 км. Трубопровод «Голубой поток» был построен в рамках российско-турецкого соглашения от 1997, по которому Россия должна поставить в Турцию 364,5 млрд куб. м газа в 2000—2025 гг. В 1999 году был подписан Протокол о взаимном применении сторонами льготного налогового режима к проекту «Голубой поток». Затраты на строительство составили $3,2 млрд.

Строительство осуществлялось российско-итальянской компанией «Blue strim payplain company B. В.», которой в равных долях владели «Газпром» и итальянская Eni. Сейчас эта компания выступает владельцем морского участка газопровода, включая компрессорную станцию «Береговая» в Архипо-Осиповке (наиболее мощную в мире).

«Уренгой — Помары — Ужгород» — советский магистральный экспортный газопровод. Соединяет газовые месторождения севера Западной Сибири с Ужгородом на Западной Украине. Далее газ транспортируется конечным потребителям в Центральной и Западной Европе. Пересекает российско-украинскую границу севернее города Сумы. По Украине газ транспортируется до компрессорной станции в районе Ужгорода на украинско-словацкой границе и к меньшим компрессорным станциям на венгерской и румынской границах. Трубопровод пересекает Уральский хребет и более 600 рек, включая Обь, Волгу, Дон и Днепр.

Проект экспортного трубопровода был предложен в 1978 году от месторождений Ямбурга, но позже был изменен на трубопровод от Уренгойского месторождения, которое уже эксплуатировалось.

Газопровод был построен в 1982-1984 годы. Он создал трансконтинентальную систему транспортировки газа Западной Сибири в Западную Европу, официальная церемония инаугурации состоялась во Франции. Общая длина — 4 451 км, мощность — 32 млрд кубометров газа в год. Диаметр каждой из трех ниток — 1420 мм. Протяженность по территории Украины — 1 160 км, на трассе находятся девять компрессорных станций.

«Ямал — Европа» — российский магистральный экспортный газопровод, построенный предприятием Ленгазспецстрой. Соединяет газовые месторождения севера Западной Сибири с конечными потребителями в Западной Европе. Проходит через территорию Белоруссии и Польши.

Пропускная способность газопровода Ямал—Европа — около 30 млрд кубометров газа в год. «Северный поток» (ранее Северо-Европейский газопровод ) — газопровод между Россией и Германией по дну Балтийского моря, соглашение о строительстве которого было подписано в начале сентября 2005. «Южный поток» (англ. South Stream) — российско-итальяно-французский проект газопровода, который пройдёт по дну Чёрного моря из Новороссийска в болгарский порт Варну. Далее его две ветви пройдут через Балканский полуостров в Италию и Австрию, хотя их точные маршруты пока не утверждены. Согласно планам, газопровод должен вступить в строй к 2015 году. Планируемая мощность «Южного потока» — 63 млрд кубометров газа в год. Оценочная стоимость проекта — 8,6 млрд евро.

Определение рабочей области моделирования

Установка четких границ области проекта может быть определена с помощью методики «будет/не будет». Используя данную методику, определим, какие объекты и процессы будут принадлежать рассматриваемой предметной области.

Проект будет:

  • внешним, т.к. между системами будет передаваться информация по заправочным станциям ООО «Газпром трансгаз Томск»;

  • предназначен только для сотрудников филиалов компании, бухгалтерии, отдела кадров, автопарка и водителей ООО «Газпром трансгаз Томск»;

Проект не будет:

  • не предусматривает доступ неавторизированных пользователей компании (только для прошедших аутентификацию);

  • не будет полномасштабной системой, т.к. не рассматривает только дочернее предприятие ОАО «Газпром» - ООО «Газпром трансгаз Томск», обеспечивающее поставки газа потребителям в 13 регионах Сибири и Дальнего Востока. ОАО «Газпром» в целом

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

  1.  
    1. Постановка задачи

ООО «Газпром трансгаз Томск» - 100-процентное дочернее предприятие ОАО «Газпром», обеспечивающее поставки газа потребителям в 13 регионах Сибири и Дальнего Востока. В зонах производственной деятельности Общества эксплуатируется более 9 тыс. км магистральных нефти- и газопроводов (МГ). Ежегодный объем транспортируемого предприятием газа — более 17 млрд куб. м. В составе Общества 22 филиала, в том числе 16 линейных производственных управлений (ЛПУ) МГ, 9 компрессорных станций (КС), 1 насосно-компрессорная станция (НКС), 34 газоперекачивающих агрегата (ГПА), 133 газораспределительных станций (ГРС) и контрольно-распределительных пунктов, 11 автомобильных газонаполнительных компрессорных станций (АГНКС).

Менеджмент качества Общества соответствует требованиям стандартов СТО Газпром 9001–2006 (часть I и II), ИСО 9001:2008, ГОСТ Р ИСО 9001–2008. Обществом внедрена система экологического менеджмента ISO 14001:2004. Коллектив предприятия насчитывает более 6500 человек.

ООО «Газпром трансгаз Томск» (далее — Общество) — 100 % дочернее общество ОАО «Газпром», имеющее более чем 35-летнюю историю. Общество является самым восточным газотранспортным предприятием, осуществляет транспортировку газа потребителям Западной Сибири и Дальнего Востока, входит в единую газотранспортную систему ОАО «Газпром», реализует стратегию ОАО «Газпром» по развитию газотранспортной системы в Восточной Сибири и на Дальнем Востоке.

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

Поставленные задачи ООО «Газпром трансгаз Томск» реализует на основе следующих принципов:

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

Рисунок 1- Организационная структура компании

  • непрерывное совершенствование системы управления производственными процессами, внедрение передовых технологий, новых форм и методов управления производственно-хозяйственной деятельностью;

  • поддержание в рабочем состоянии и развитие системы менеджмента качества Общества, соответствующей требованиям актуальных версий стандартов СТО Газпром 9001, ISO 9001, ГОСТ ISO 9001;

  • постоянное повышение результативности системы менеджмента качества;

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

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

  • доведение до всех работников Общества задач, полномочий и ответственности в области качества.

На сегодняшний день на газодобывающем предприятииООО «Газпром трансгаз Томск» имеется собственный парк автомобильной и специальной техники, который в свою очередь нуждается в учете и контроле запасных частей. Автопарк - сложное хозяйство. Особенно если производственная деятельность разнопланова, а сам парк машин обширен по составу и назначению автотранспортных единиц. Для автоматизированного учета рабочей деятельности автопарков можно использовать универсальные программные продукты, созданные для целей учета. Однако универсальное всегда проигрывает специализированному. Потому что в программе, созданной для решения конкретных задач, можно предусмотреть все нюансы производственной деятельности. Такой специализированной программой является система SIKE.Автопарк.Она позволяет создать единую централизованную систему управления автотранспортом.

Анализ и описание ИУС SIKE.Автопарк

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

С помощью ИУС «SIKE.Autopark» могут быть автоматизированы такие бизнес-процессы, как: долгосрочное и краткосрочное планирование работы автотранспорта; формирование, печать, обработка путевых листов; учет и контроль расхода топлива с использованием систем ГЛОНАСС/GPS; распределение транспортных затрат по местам возникновения (МВЗ); формирование и контроль графиков проведения ТО; ремонт автотранспорта; контроль пробега запчастей и агрегатов; учет выдачи и списания АКБ; учет и контроль пробега шин; учет ОСАГО, КАСКО; вахтовые перевозки.

Так же на предприятиях разработаны механизмы автоматического обмена справочной информацией между ИУС «SIKE.Autopark» , ERP-системой и системой управления персоналом через центр интеграции [13].

Для руководителей автотранспортного управления в ИУС разработана подсистема «АРМ Руководителя», благодаря которой можно в оперативном режиме получать информацию о ключевых показателях эффективности работы автотранспорта в отдельно взятом филиале и по компании в целом. АРМ имеет гибкую систему настроек, позволяющую собственными силами оперативно создавать новые и корректировать существующие показатели [2].

Внедрение ИУС» SIKE.Autopark», по анализу корпоративных администраторов предприятия ООО «Газпром трансгаз Томск», способствовало оздоровлению экономики предприятия за счет шести основных и ряду дополнительныхфункциональныхособенностейкорпоративнойинформационной системы. На каждую деталь, с определенным идентификационным номером, есть возможность получать аналитическую информацию о пробеге номерных агрегатов и об истории установки деталей. Программа Путевые листы (программа Автопарк) может автоматически блокировать ряд операций, приводящих к неэффективному использованию запчастей. Аналитические инструменты КИС позволяют выявить единицы техники, объекты, водителей с повышенным расходом ресурсов.

Рисунок 2. - Контроль над пробегом и расходом запчастей.

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

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

Программа АВТОПАРК на основании оперативно получаемой информации позволяет вести учёт пробегов автомобилей, расхода ГСМ и выполненных работ. Позволяет формировать аналитическую отчётную информацию в разрезе, удобном для пользователя.

Рисунок 3. - Планирование и учет фактических доходов и расходов.

Рисунок 4. - Оптимизация перевозок, анализ загруженности транспорта.

Оборотные средства АТП в виде запасов автозапчастей и ГСМ часто представляют значительное отвлечение денежных средств из оборота. Программа АВТОПАРК позволяет не только вести учет складского хранения, но и рассчитывать оптимальные нормы хранения каждого наименования, выявлять неликвидные и залежалые позиции, позиции с малыми остатками, о чем своевременно оповещать службы снабжения в виде соответствующих заявок и отчетов.

Рисунок 5. -Учет работы автотранспорта (путевые листы).

Рисунок 6. - Складской учет

Учет ремонтов в системе управления автотранспортом SIKE. АВТОПАРК обеспечивает учет затрат на ремонты, ведение истории ремонтов, ведение истории пробегов агрегатов и данных о сотрудниках, производивших ремонт, что обеспечивает необходимую управленческую статистику.

Анализ и описание ИУС «КАСУН»

Так же в состав газодобывающего предприятия входят ведомственные заправочные станции, на которых установлена комплексная автоматизированная система управления нефтепродуктообеспечением (КАСУН). Система предназначена для автоматизации процесса приема, отпуска и учета нефтепродуктов, а также мониторинга наличия нефтепродуктов на ведомственных автомобильных заправочных станциях.

Рисунок 7. - Учет ремонтов

Система позволяет вести круглосуточный безоператорный отпуск и учёт нефтепродуктов сети ведомственных АЗС. Авторизация водителей (или транспортных средств) на терминалах безоператорного отпуска происходит с использованием электронных идентификационных карт или электронных ключей. Опционально может производиться идентификация путевого листа. Безоператорный отпускреализуется с использованием терминалов безоператорного отпуска КАЗС-АСИ-2.0 «Поток», интегрированных с ТРК АЗС. Терминал подключается к корпоративной сети передачи данных, и использует справочную информацию системы верхнего уровня. Терминал может подключаться к TCP/IP сети предприятия как непосредственно, так и через программно-аппаратные шлюзы, посредством GSM, радио или спутниковой связи. Система исключает оборот наличных средств при заправке ведомственного транспорта, позволяет вести точный учёт приёма и отпуска нефтепродуктов на АЗС, позволяет задавать лимиты отпуска топлива с привязкой к транспортным средствам или водителям, исключает несанкционированный забор топлива из АЗС, позволяет вести ежедневный и круглосуточный отпуск топлива без участия оператора [3].

Так же в основу системы были положены следующие базовые характеристики:

  1. Безоператорный отпуск 24х7

Система позволяет управлять процессами приёма, хранения и отпуска ГСМ на складах хранения и перевалки ГСМ, на АЗС в автоматическом круглосуточном режиме, без участия оператора, при помощи терминала безоператорного отпуска ГСМ. Отпуск ГСМ производится по персонифицированным электронным ключам или электронным картам. Учёт отпускаемых ГСМ производится с привязкой к водителям/транспортным средствам/путевым листам.

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

2. Работа в корпоративной сети

Система способна работать как при постоянном подключении к корпоративной сети, так и в автономном режиме. Для подключения к корпоративной сети предприятия могут быть использованы как открытые каналы передачи данных (интернет, радиосвязь), так и прямое подключение к закрытой частной сети предприятия. Информация о состоянии технологического оборудования, запасах топлива, произведенных отпусках топлива или внутрипарковых перемещениях объемов топлива передаётся на центральный диспетчерский пункт в режиме online, либо в режиме отложенной загрузки. В тоже время, система «нечувствительна» к типу каналов связи: это может быть прямое кабельное соединение, радиоканал, GSM-соединение, или TCP/IP сеть предприятия.

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

3. Автономный режим

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

4. Аналитические инструменты

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

Даёт возможность планировать бюджет на ГСМ, планировать оптимальные объёмы закупки ГСМ, оптимизировать логистику доставки ГСМ на объекты топливной инфраструктуры.

5. Быстрая и легкая масштабируемость

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

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

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

Система будет интересна промышленным предприятиям, предприятиям добывающей отрасли, транспортным предприятиям, предприятиям речного и воздушного транспорта.

Разработка модели AS-IS бизнес-процессов

Модель AS-IS или модель «как есть» представляет собой модель бизнес-процессов на момент обследования предприятия и строится с целью понять, как функционирует данное предприятие с позиций системного анализа. Эта модель строится с целью выявления ошибок и «узких мест», а также формулировка предложений по улучшению ситуации.

Чтобы более подробно рассмотреть процесс учета автомобилей и путевых листов в Администрации Газпром и его филиалах, была создана диаграмма eEPC методологии Aris (Приложение А) и диаграмма DFD (Приложение Б).

Определение «узких» мест и выработка предложений по их устранению.«Узким местом» называют момент падения производительности системы. «Узкие места» будем определять на основе анализа построенной модели (см. Рис. 3). Проанализировав модель «AS-IS» можно выделить следующие «узкие места»:

  • расчет остатков ГСМ по путевым листам, перетаксировка и составление отчетов требуют больших трудозатрат и большой концентрации внимания;

  • большое количество документов ведется в бумажной форме;

  • невозможность предоставления оперативной отчетности руководству;

  • возможные ошибки диспетчера при регистрации количества заправленного топлива водителем (например, не разобрав почерк водителя, регистрируя другие количественные показатели, что может привести к несоответствию отчетов и искажению информации);

  • и другие

Управленческое решение об интеграции «SIKE.Autopark» и «КАСУН» на предприятии ООО «Газпром трансгаз Томск» было предложено и принято Заказчиком. Данное решение позволит сократить время обработки путевых листов и исключит в них несоответствия по заправкам с данными системы КАСУН. Решение будет реализовано посредством организации обмена данными между ИУС «SIKE.Autopark» и системой КАСУН.

Обоснование выбора управленческого решения

Для того чтобы наглядно представить процесс интеграции ИУС» SIKE.Autopark» и «КАСУН», рассмотрим приведенные ниже модели (рис. 1 – Общая схема обмена данными, рис.2 – Схема передачи данных из центральной базы предприятия в базы филиалов).

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

Рассмотрим подробнее. Данные о путевых листах и о справочнике автомобилей будут передаваться в центр интеграции (далее) ЦИ. Для передачи будут использованы разработанные алгоритмы передачи данных. Также будут разработаны алгоритмы передачи данных о путевых листах и о справочнике автомобилей из ЦИ в систему КАСУН.

Для дальнейшей автоматизации передачи данных о заправках в путевые листы. Данные о фактах заправки буду загружаться в ЦИ из системы КАСУН в таблицу «Факты заправки». Для передачи будут использованы алгоритмы передачи данных. Таким же образом из системы КАСУН в ЦИ будут загружены данные о заправочных станциях, в таблицу «Заправочные станции».

Главным неизменным полем таблицы будет являться поле ID» (Идентификатор заправки, счетчик). Поле «Pl_ID» является идентификатором принадлежности данных конкретному филиалу, по которому вдальнейшем SIKE будет раздавать записи конкретному филиалу. Поле «AutomobID» является вспомогательным полем для проверки принадлежности автомобиля, совершившего заправку, к путевому листу, покоторому совершена заправка, и проверяется на соответствие допередачи в ЦИ из КАСУН.

Главным неизменным полем таблицы будет являться поле «ZapravkaID» (Идентификатор заправочной станции, счетчик).

Далее, для реализации обмена данными между ИУС» SIKE.Autopark» и системой КАСУН будет организована выгрузка данных о фактах заправки из ЦИ в центральную базу данных предприятия посредством настройки задания в планировщике задач SQL Server (JOB), запускающем SQL процедуру с периодичностью не более 10 минут. Таким же образом будут выгружены данные о заправочных станциях, но с периодичностью запуска не более 30 минут. Для хранения данных о фактах заправки в 01БД будет создана таблица, идентичная таблице «Факты заправки». А для хранения данных о заправочных станциях будет использоваться существующая таблица справочника «Заправки». Далее данные будут передаваться в филиалы предприятий посредством файловой репликации корпоративной сети. Ниже на рис. 9 представлена схема передачи данных из центральной базы предприятия в базы филиалов. При изменении данных в филиалах будет произведена перетаксировка данных, и пользователям будут отправляться E-mail оповещения, что позволит своевременно среагировать и пересмотреть ранее созданные отчетности.

Выводы по главе 1

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

На данный момент на предприятии существует большой парк автомобильной и специальной техники и ведомственных заправок, которые нуждаются в учете. Данную функцию успешно выполняют системы ИУС «SIKE.Autopark» и система КАСУН. Заказчиком выявлено, что существует ряд бизнес процессов нуждающихся в автоматизации.

ГЛАВА 2 РАЗРАБОТКА ПРОЕКТНЫХ РЕШЕНИЙ

2.1 Технические требования заказчика к задаче «Интеграция модуля «ПЛ 3.0» и системы КАСУН»

Цель: интеграция данных по заправкам1 из программного средства КАСУН в модуль путевых листов.

Описание: В центре интеграции (Далее – ЦИ), располагается представление (view) «dbo. Kasun WU». Вот его описание:

Поле

Тип

Описание

Key

int

Идентификатор заправки, счетчик

Auto

int

Ссылканаполетаблицы XXX_01.XXXXXXX

Date

datetime

Дата выдачи топлива

Cut

float

Количество выданного топлива

Top

int

Ссылка на поле таблицы XXX_01.XXXXXXX

Accep

datetime

Дата аккредитации (проверки и принятия данного факта заправки)

Putlist

int

Ссылка на поле таблицы XXX_01.XXXXXXX

Zapravk

Int

Ссылканаполетаблицы XXX_01.XXXXXXX

В ней хранится информация по заправке ТС из системы КАСУН. К интеграции допускаются лишь те записи, в которых указан ПЛ, количество и тип топлива, указано ТС, а так же факт заправки является доверительным.

Обновление данной таблицы происходит не реже одного раза в час.

В центре интеграции (Далее – ЦИ), располагается представление (view) «dbo.kasun_ZapravkaWU». Вот его описание:

Поле

Тип

Описание

ZapravkaID

int

Идентификатор заправочной станции

Zapravka

Nvarchar(200)

Название заправочной станции

В ней хранится информация по заправочным станциям, с которых идёт отпуск топлива для ТС.

Обновление данной таблицы происходит по требованию (при вводе заправочной станции в эксплуатацию).

Задача:

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

Необходимо импортировать данные о фактах выдачи топлива в модуль путевых листов ИУС «Sike.Автопарк» посредством сбора информации о фактах заправки в ЦИ. Импорт данных должен происходить не позднее 10 минут после обновления информации в ЦИ. Передача данных (передача и принятие информации) на филиал (посредством репликации) должна осуществляться не позднее 20 минут после обновления информации в ЦИ. Данные в ЦИ могут меняться: факт заправки может быть перенесен с одного ПЛ на другой и т.д. Неизменным остается лишь поле «ID».

В форме редактирования ПЛ, если выдача топлива была осуществлена на заправочной станции КАСУН, то редактирование данной записи должно быть заблокировано (так же, как и возможность удаления данной записи).

Если в ПЛ уже присутствует идентичная запись о заправке (совпадает марка топлива, его количество, дата заправки), то такую запись необходимо заменить на данные из ЦИ. Необходимо хранить информацию о пользователе, который закрывал ПЛ.

Решение конфликтных ситуаций:

Необходимо добавить общие настройки в модуль Администрирование с названием «КАСУН. Автоматическая перетаксировка», и «КАСУН. E-mail информирования» (может содержать несколько e-mail адресов).

Если ПЛ, для которого осуществляется импорт данных, уже обработан, то необходимо:

  1. Если настройка «КАСУН. Автоматическая перетаксировка» включена, то:

    1. добавить информацию о выдаче топлива из КАСУН;

    2. перетаксировать ПЛ;

    3. если значения по таксировке (конечное кол-во топлива и т.п.) в ПЛ изменились, от отправить об этом оповещение на e-mail лицу, закрывшему этот ПЛ о том, что произошла перетаксировка и значения изменились.

  2. Если настройка «КАСУН. Автоматическая перетаксировка» включена, то:

    1. добавить информацию о выдаче топлива из КАСУН;

    2. снять пометку «Закрытый ПЛ» с ПЛ;

    3. отправить об этом оповещение на e-mail лицу, закрывшему этот ПЛ о том, что произошло изменение в информации о выданном топливе.

  3. Если такого ПЛ на филиале не существует или для данного автомобиля указано неверная марка топлива или существуют другие конфликты, то:

    1. Отправить об этом оповещение на e-mail адрес, указанный в настройке «КАСУН. E-mail информирования».

Если ПЛ, для которого осуществляется импорт данных, не существует на базе Администрации, то необходимо всё равно передать эти данные в филиал и проверить наличие ПЛ в филиале (филиал можно определить по автомобилю, указанному в ЦИ).

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

Техническое задание на создание алгоритма «Передача данных о заправочных станциях».

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

Описание алгоритма

Алгоритм предназначен для передачи данных о заправочных станциях из Центра интеграции в систему SIKE.Autopark.

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

Таблица в ЦИ: Kasun_Zapravka

Таблица в SIKE: SpZapravka

Таблица хранит информацию по заправочным станциям.

ЦИ таблица

SIKE таблица SpZapravka

Наименование поля

Тип поля в БД

Имя поля в БД

Наименование поля

Тип поля в БД

Имя поля в БД

 

Int

ZapravkaID

Идентификационный номер

type_id

ZapravkaID

 

Nvarchar(200)

Zapravka

Наименование заправки

type_str

Zapravka

 

Datetime

RC_Date

Дата изменения записи

type_date

RC_Date

 

varchar(1)

Tp_Int

Тип изменения записи

varchar(1)

Tp_Int

       

type_bool

HD_INT

1. При запуске процедуры производится выборка записей о заправочных станциях, которые хранятся в ЦИ, во временную таблицу. В данную (временную) таблицу добавляется дополнительное поле DoIT . Тип поля DoIT : Целое число. Так же при запуске процедуры создается результирующая таблица, в которой создаются скрипты.

2. В полученной временной таблице производится заполнение поля DoIT по следующему алгоритму:

Если (Код ZpID из ЦИ не равен ZpID в 01 БД

или Код ZpID из ЦИ равен ZpID в 01 БД)

или

(Код ZpID из ЦИ не равен ZpID в 01 БД

или Date в ЦИ больше Date в 01 БД)

то Запись помечается на обработку: полю DoIT присваивается значение 1.

Иначе Запись помечается на удаление: полю DoIT присваивается значение 0.3. В полученной временной таблице все записи со значением поля DoIT =1 проходят обработку по следующему алгоритму:

- Шаг 1: Если Tp_Int в ЦИ равен «I», то

Если Код ZpID из ЦИ равен ZpID в 01 БД, то

Присвоение полю Tp_Int Значения «U»; переход к Шагу 2.

Иначе Добавление в результирующую таблицу записи, идентичной записи в ЦИ, содержащую скрипт для добавления записи (Для всех добавляемых записей устанавливается HD_INT ='F').

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующую таблицу, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

- Шаг 2: Если Tp_Int в ЦИ равен «U», то

Если Код ZpID из ЦИ равен ZpID в 01 БД, то

добавляем записи в результирующую таблицу, содержащую скрипт для обновления записи в 01 БД в соответствии с данными ЦИ (Для всех добавляемых записей устанавливается HD_INT ='F');

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующей таблицы, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

Иначе присвоение полю Tp_Int значения «I»; переход к Шагу 1.

- Шаг 3: Если Tp_Int в ЦИ равен «D», тоДобавление в результирующую таблицу записи, идентичной записи в ЦИ, содержащую скрипт для добавления записи (Для всех добавляемых записей устанавливается HD_INT ='T').

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующей таблицы, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

Результат:

Данные в системе SIKE.Autopark в таблице Запрвка становятся идентичными данным в таблице Заправка из ЦИ.

2.2 Разработка частного технического задания на алгоритм обработки данных на филиалах

Техническое задание на создание алгоритма «Обработка данных на филиалах».Алгоритм – это конечный набор правил, который определяет последовательность операций для решения конкретного множества задач и обладает пятью важными чертами: конечность, определённость, ввод, вывод, эффективность» (Д.Э. Кнут). Ряд общих требований предъявляемых к алгоритму: детерминированность-определенность, понятность, завершаемость (конечность), массовость. ТЗ заполняется заказчиком, в случае возникновения трудностей в заполнении – совместно с программистом или постановщиком, затем передается на рецензирование и подпись.

Описание алгоритма

Алгоритм предназначен для переноса данных о фактах заправки из таблицы Kasun в таблицу Plisl в системе SIKE.Autopark.

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

Таблица в SIKE: Kasun

Таблица в SIKE: Plisl

Таблица хранит информацию о фактах заправки.

SIKE таблица Kasun

 

Наименование поля

Тип поля в БД

Имя поля в БД

 

Идентификатор заправки, счетчик

type_id

ID

 

Ссылка на поле таблицы

type_id

AutomobID

 

Дата выдачи топлива

type_date

DateOut

 

Количество выданного топлива

type_currency

Co_Int

 

Ссылка на поле таблицы

type_id

Benz_ID

Дата аккредитации (проверки и принятия данного факта заправки)

datetime

AcceptDate

Ссылка на поле таблицы

type_id

Pl_ID

Наименование заправки

type_id

ZapravkaID

Дата изменения записи

type_date

RC_Date

Тип изменения записи

varchar(1)

Tp_Int

 

type_bool

HD_INT

 

varchar(1)

New

Таблица хранит информацию по заправкам в путевых листах.

SIKE таблица Plisl

Наименование поля

Тип поля в БД

Имя поля в БД

Идентификатор заправки, счетчик

type_id_inc

plistBenz_ID

 

type_currency

CenaToplDop

 

type_bool

is_ToplDopDvig

 

type_bool

is_InTmc

Количество заправленного топлива

type_currency

KolTopl

 

type_currency

KolToplTO

Ссылка на поле таблицы

type_id

Pl_ID

Ссылка на поле таблицы

type_id

Benz_ID

 

type_str

user_modif

Ссылка на поле таблицы

type_id

ZapravkaID

 

type_currency

KolToplProgrev

 

type_bool

is_altertopl

 

type_bool

is_Smes

 

type_bool

is_PredpuskPodogrev

 

type_bool

is_ToplDopDvig2

 

type_bool

is_ToplDopDvig3

При запуске процедуры открываем транзакцию на таблицу Kasun . За тем во временную таблицу выбираем все записи таблицы Kasun , у которых значение поля New равно NULL.

Обработка записей временной таблицы у которых значение поля New равно NULL.

Если(1) Значение поля New записи из таблицы Kasun равно NULL

то

Если(2)ID обрабатываемой записи из администрации равно ID записи на филиале

То

Если(3)Pl_ID обрабатываемой записи из администрации равен Pl_ID из Kasun на филиале то

Если(4)поле Pl_ID записи из Kasun администрации равен Pl_ID из Kasun на филиале, то

Если(5) поле Co_Int записи из администрации равно полю Co_Int записи на филиале

и/или

поле Benz_ID записи из администрации равно Benz_ID записи на филиале то

необходимо перенести данные из Kasun в Plisttopl;

Функция_1

(Начало)

Во временной таблице для обрабатываемой записи таблицы Kasun устанавливаем значение поля New равно F;

Еслипоследняя запись таблицы Kasun , у которой значение поля New равно NULLто

- в таблицу Kasun филиала в поле New присваиваем значение F, для записей с аналогичными ID записям обработанным во временной таблице;

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

- закрытие транзакции на таблицу Kasun ;

- завершаем процедуру:

Иначе переход к обработке следующей записи (Если(1))

(Конец)

Иначе(5)необходимо перенести данные из Kasun в Plisttopl;

Если(6)значение поля is_ DoIT ot записи равно «Т» в таблице Plist с Pl_ID равным Pl_ID из обрабатываемой записи, то

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

Если(7)при перетаксировке получены отрицательные данные по остаткам топлива то

полю is_ DoIT ot записи присваиваем значение «F»

значения таксировки не сохраняем;

необходимо отправить е-mail оповещение о нехватке топлива;

ЕслиАвтомобиль указанный в таблице Kasun соответствует типу заправленного топлива из таблицы Automob, то отправка E-mailоповещения пользователю о движении топлива;

Функция_1;

Иначеотправка E-mail оповещения пользователю о несоответствии типа топлива;

Функция_1;

Иначе(6)

Функция_1;

Иначе(5)Добавление записи в таблицу изменений с содержанием ID, добавляемого Pl_ID записи из администрации и ранее содержащегося Pl_ID записи филиала из которой будет перенесена заправка;

перенос данных из Kasun в Plisttopl,перетаксировка по двум путевым листам, по Pl_ID филиала и Pl_ID администрации.

Еслипри перетаксировке получены отрицательные данные то

значения таксировки не сохраняем

Необходимо отправить е-mail оповещение о нехватке топлива;

Если(8)Автомобиль указанный в таблице Kasun соответствует типу заправленного топлива из таблицы Automob, то отправка E-mail оповещения пользователю о движении топлива;

Функция_1;

Иначе(8)отправка E-mail оповещения пользователю о несоответствии типа топлива;

Функция_1;

Иначе(3)

Функция_1;

Если(9)Pl_ID обрабатываемой записи из администрации равен Pl_ID таблицы Plist на филиале, топеренос данных из Kasun в Plisttopl;

Если(10)значение поля is_ DoIT ot записи равно «Т» в таблице Plist с Pl_ID равным Pl_ID из обрабатываемой записи, топеретаксировка путевого листа;

Еслипри перетаксировке получены отрицательные данные то

Необходимо отправить е-mail оповещение о нехватке топлива;

ЕслиАвтомобиль указанный в таблице Kasun соответствует типу заправленного топлива из таблицы Automob, то отправка E-mail оповещения пользователю о движении топлива;

Функция_1;

Иначеотправка E-mail оповещения пользователю о несоответствии типа топлива;

Функция_1;

Иначе(10)

Функция_1;

Иначе(9) отправка E-mail оповещения администратору;

Функция_1;

Сообщения для E-mail оповещения

Сообщение пользователю об изменении движения топлива

В путевом листе Номер: , дата открытия: , дата закрытия: были изменены данные о количестве выданного топлива и произведена перетаксировка.

Сообщение пользователю о несоответствии марки топлива

В путевом листе Номер: , дата открытия: , дата закрытия: была произведена заправка автомобиля топливом, марка которого не соответствует автомобилю, указанному в путевом листе. Так же была произведена перетаксировка данного путевого листа.

Сообщение пользователю о нехватке топлива

В путевом листе Номер: , дата открытия: , дата закрытия: при выполнении таксировки была выявлена ошибка: «Фактический расход, больше наличия топлива в баке». У данного путевого листа снят признак «Обработан».

Результат:

Данные в системе SIKE.Autopark переносятся из таблицы Kasun в таблицу Plisttopl.

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

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

Техническое задание на создание алгоритма «Передача данных о фактах заправки». Алгоритм – это конечный набор правил, который определяет последовательность операций для решения конкретного множества задач и обладает пятью важными чертами: конечность, определённость, ввод, вывод, эффективность» (Д.Э. Кнут). Ряд общих требований предъявляемых к алгоритму: детерминированность-определенность, понятность, завершаемость (конечность), массовость. ТЗ заполняется заказчиком, в случае возникновения трудностей в заполнении – совместно с программистом или постановщиком, затем передается на рецензирование и подпись.

Описание алгоритма

Алгоритм предназначен для передачи данных о фактах заправки.

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

Таблица в ЦИ: Kasun

Таблица в SIKE: Kasun

Таблица хранит информацию по фактам заправки.

ЦИ таблица

SIKE таблица Kasun

 

Наименование поля

Тип поля в БД

Имя поля в БД

Наименование поля

Тип поля в БД

Имя поля в БД

 
 

Int

ID

Идентификатор заправки, счетчик

type_id

ID

 
 

Int

AutomobID

Ссылка на поле таблицы dbo.spAutomob.AutomobID

type_id

AutomobID

 
 

Datetime

DateOut

Дата выдачи топлива

type_date

DateOut

 
 

Float

Co_Int

Количество выданного топлива

type_currency

Co_Int

 
 

Int

Benz_ID

Ссылка на поле таблицы dbo.spTopl.Benz_ID

type_id

Benz_ID

 

Datetime

AcceptDate

Дата аккредитации (проверки и принятия данного факта заправки)

datetime

AcceptDate

 

Int

Pl_ID

Ссылка на поле таблицы dbo.PList.Pl_ID

type_id

Pl_ID

 

Int

ZapravkaID

Наименование заправки

type_id

ZapravkaID

 

Datetime

RC_Date

Дата изменения записи

type_date

RC_Date

 

varchar(1)

Tp_Int

Тип изменения записи

varchar(1)

Tp_Int

       

type_bool

HD_INT

       

varchar(1)

New

1. При запуске процедуры производится выборка записей о фактах заправки, которые хранятся в ЦИ, во временную таблицу. В данную (временную) таблицу добавится дополнительное поле DoIT (тип поля: Целое число). Также при запуске процедуры создается результирующая таблица, в которой в свою очередь создаются скрипты.

2. В полученной временной таблице производится заполнение поля DoIT по следующему алгоритму:

Если (Код ID из ЦИ не равен ID в 01 БД

или Код ID из ЦИ равен ID в 01 БД)

или

(Код ID из ЦИ не равен ID в 01 БД

или Date в ЦИ больше Date в 01 БД)

тоЗапись помечается на обработку: полю DoIT присваивается значение 1.

Иначе Запись помечается на удаление: полю DoIT присваивается значение 0.3. В полученной временной таблице, все записи, со значением поля DoIT =1, проходят обработку по следующему алгоритму:

- Шаг 1: Если Tp_Int в ЦИ равен «I», то

Если Код ID из ЦИ равен ID в 01 БД, то

Присвоение полю Tp_Int Значения «U»; переход к Шагу 2.

ИначеДобавление в результирующую таблицу записи, содержащую скрипт для добавления записи, идентичной записи в ЦИ (Для всех добавляемых записей устанавливается HD_INT ='F', New=NULL).

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующую таблицы, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

- Шаг 2: Если Tp_Int в ЦИ равен «U», то

Если Код ID из ЦИ равен ID в 01 БД, то

добавляем запись в результирующую таблицу, содержащую скрипт для обновления записи в 01 БД в соответствии с данными ЦИ (Для обновляемых записей устанавливается HD_INT ='F', New=NULL).

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующую таблицы, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

Иначе присвоение полю Tp_Int значения «I»; переход к Шагу 1.

- Шаг 3: Если Tp_Int в ЦИ равен «D», тоДобавление в результирующую таблицу, содержащую скрипт для удаления (присвоения HD_INT ='T', New=NULL) записи в 01 БД в соответствии с данными ЦИ.

Если Запись во временной таблице последняя, то выполняем скрипты из результирующей таблицы, удаляем временную и результирующую таблицы, и завершаем выполнение процедуры.

Иначе Переход к Шагу 1.

Результат:

Данные в системе SIKE.Autopark в таблице Kasun становятся идентичными данным в таблице Kasun из ЦИ.

2.4 Разработка план-графика интеграции

Создание иерархической структуры работ

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

По рисунку мы видим, что основными задачами выделены: предпроектное обследование; планирование; проектирование; проектирование структуры интеграции; разработка ТЗ; согласование с заказчиком; согласование с руководством; поиск и отбор персонала.

Рисунок 13. - Иерархическая структура работ проекта

Ресурсы

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

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

Рисунок 14. - Лист ресурсов

Занятость ресурсов в проекте изображена на рис. 15, 16,17 (приложение И). На данном рисунке можно увидеть, сколько часов занят тот или иной ресурс в каждый из рабочих дней.

Время и стоимость

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

Так же важным фактором хода проекта является его стоимость. Во время планирования проекта ресурсам задается их стоимость. За основу стоимости работ были взяты средние рыночные цены ресурсов, а так же ставки часовых и сверхурочных работ из трудового договора. Из стоимости работы ресурсов складывается базовая стоимость проекта. Базовая стоимость проекта изображена на рис. 19 (приложение И).

Риски проекта

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

Следующий вид рисков – риски, связанные с финансированием проекта. Так как сам заказчик финансирует проект, данный риск минимизирован.

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

Исполнение, мониторинг и контроль проекта

Исполнение проекта

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

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

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

Мониторинг и контроль проекта. Ниже приведены таблицы с оценками показателей метода освоенного объема (рис. 23 в приложении И). Опираясь на показатели метода освоенного объема можно с уверенностью сказать, что руководителю необходимо предпринимать какие-либо действия по нормализации хода выполнения проекта поскольку уже к сегодняшнему дню потери разработчика составляют около 14000 рублей, и если ничего не предпринять, то с каждым днем они будут расти из-за незаконченных ранее задач.

Выводы по главе 2

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

Автоматизация учета путевых листов посредством интеграции систем ИУС «SIKE.Autopark» и системой КАСУН является оптимальным решением. Оно позволит сэкономить средства и не подвергнет риску работу систем.

ГЛАВА 3. РЕАЛИЗАЦИЯ ПРОЕКТНЫХ РЕШЕНИЙ ПО ИНТЕГРАЦИИ «SIKE.Autopark» и «КАСУН» 3.1. Реализация алгоритма передачи данных о фактах заправки и о заправочных станциях из центра интеграции в центральную базу организации

Данные о путевых листах и о справочнике автомобилей будут передаваться в центр интеграции (далее) ЦИ. Для передачи будут использованы разработанные Заказчиком алгоритмы передачи данных. Так же заказчиком разработаны алгоритмы передачи данных о путевых листах и о справочнике автомобилей из ЦИ в систему КАСУН. Общая схема передачи данных представлена на рисунке 24.

Рисунок 24 – общая схема обмена данными

Для дальнейшей автоматизации передачи данных о заправках в путевые листы Данные о фактах заправки будут загружаться в ЦИ из системы КАСУН в таблицу «Факты заправки». Для передачи будут использованы разработанные Заказчиком алгоритмы передачи данных (Приложение Г).

Таким же образом из системы КАСУН в ЦИ будут загружены данные о заправочных станциях, в таблицу «Заправочные станции».(Приложение Д)

Таблица 5 - «Факты заправки» будет представлена в следующем виде

Поле

Тип

Описание

ID

int

Идентификатор заправки, счетчик

Auto

int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата выдачи топлива

Co

float

Количество выданного топлива

Top

int

Ссылка на поле таблицы ATX_. ID

Accete

datetime

Дата аккредитации (проверки и принятия данного факта заправки)

PliD

int

Ссылка на поле таблицы ATX_. ID

ZapraD

Int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата изменения

Type

 

Тип изменения

Главным неизменным полем таблицы будет являться поле «ID» (Идентификатор заправки, счетчик). Поле «Pli» является идентификатором принадлежности данных конкретному филиалу, по которому в дальнейшем SIKE будет распределять записи по конкретным филиалам. Поле «Auto» является вспомогательным полем для проверки принадлежности автомобиля, совершившего заправку, к путевому листу, по которому совершена заправка, и проверяется на соответствие до передачи в ЦИ из КАСУН.

Таблица 6- «Заправочные станции» будет представлена в следующем виде:

Поле

Тип

Описание

ZapraD

Int

Идентификатор заправочной станции, счетчик

Zapra

Nvarchar(200)

Название заправочной станции

Date

Datetime

Дата изменения

Type

 

Тип изменения

Главным неизменным полем таблицы будет являться поле «ZapravkaID» (Идентификатор заправочной станции, счетчик).

Далее, для реализации обмена данными между ИУС «SIKE.Autopark» и системой КАСУН организована выгрузка данных о фактах заправки из ЦИ в базу данных администрации общества (далее 01 БД) посредством настройки задания в планировщике задач SQL Server (JOB), запускающем SQL процедуру с периодичностью не более 10 минут. Таким же образом будут выгружены данные о заправочных станциях, но с периодичностью запуска не более 30 минут. Для хранения данных о фактах заправки в 01 БД будет создана таблица, идентичная таблице «Факты заправки». А для хранения данных о заправочных станциях будет использоваться существующая таблица справочника «Заправки».

3.2. Реализация алгоритма обработки данных на филиалах, при передаче из центральной базы в базы филиала

Для дальнейшей интеграции ИУС «SIKE.Autopark» и системой КАСУН осуществлена организация обмена данными между центральной базой организации и базами данных филиалов (рис.26).

Данное решение реализовано посредством настройки задания в планировщике задач SQL Server (JOB), запускающем SQL процедуру с периодичностью не более 20 минут. Для хранения данных о фактах заправки в в базах филиалов будет создана таблица, идентичная таблице «Факты заправки» в центральной базе организации.

Таблица 7 - «Факты заправки» будет представлена в следующем виде:

Поле

Тип

Описание

ID

int

Идентификатор заправки, счетчик

Auto

int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата выдачи топлива

Co

float

Количество выданного топлива

Top

int

Ссылка на поле таблицы ATX_. ID

Accete

datetime

Дата аккредитации (проверки и принятия данного факта заправки)

PliD

int

Ссылка на поле таблицы ATX_. ID

ZapraD

Int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата изменения

Type

 

Тип изменения

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

Рисунок 26 – Общая схема обмена данными

Данное решение реализовано посредством настройки задания в планировщике задач SQL Server (JOB), запускающем SQL процедуру с периодичностью не более 20 минут. Для хранения данных о фактах заправки в в базах филиалов будет создана таблица, идентичная таблице «Факты заправки» в центральной базе организации.

Таблица 8 -«Факты заправки» будет представлена в следующем виде:

Поле

Тип

Описание

ID

int

Идентификатор заправки, счетчик

Auto

int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата выдачи топлива

Co

float

Количество выданного топлива

Top

int

Ссылка на поле таблицы ATX_. ID

Accete

datetime

Дата аккредитации (проверки и принятия данного факта заправки)

PliD

int

Ссылка на поле таблицы ATX_. ID

ZapraD

Int

Ссылка на поле таблицы ATX_. ID

Date

datetime

Дата изменения

Type

 

Тип изменения

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

Рисунок 27 – Алгоритм передачи данных на филиалы

Выводы по главе 3

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

Автоматизация учета путевых листов посредством интеграции систем ИУС «SIKE.Autopark» и системой КАСУН является оптимальным решением. Оно позволит сэкономить средства и не подвергнет риску работу систем.

ГЛАВА 4 Расчет затрат на интеграцию «SIKE.Autopark» и «КАСУН» 4.1 Расчет экономических инвестиций в интеграцию «SIKE.Autopark» и «КАСУН»

В процессах разработки интеграции примут участие 16 специалистов. Ниже представлены данные специалистов (должность, ставка, трудозатраты в часах, стоимость оказания услуг в рублях):

Рисунок 24. - Ресурсы

Для расчета продолжительности и стоимости разработки, интеграции систем был разработан план-график на основе стандарта ГОСТ 34.601-90 (Приложение Е):

Таблица 8 − Затраты по статьям

Статья затрат

Затраты

Формирование требований к интеграции

80 640,00 р.

Разработка концепции интеграции

49 600,00 р.

Разработка эскизного проекта

14 400,00 р.

Разработка технического проекта

13 680,00 р.

Рабочий проект

370 906,00 р.

Ввод в действие

31 440,00 р.

Рисунок 27. - Затраты на разработку и реализацию интеграции систем

Данная диаграмма показывает затраты на разработку и внедрение АИС. Самые большие финансовые затраты на этапе «Рабочий проект», поэтому данному процессу необходимо уделить максимальное внимание.

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

Реализация выработанного плана-графика займёт 92 рабочих дня, а его стоимость составит 138 976,00 руб.

4.2 Экономический эффект от интеграции «SIKE.Autopark» и «КАСУН»

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

(1),

Где ∆Эгод − годовая экономия (прибыль), вызванная ИС, без учета эксплуатационных затрат на ИС;

С − эксплуатационные затраты на ИС;

К − единовременные затраты (капиталовложения), связанные с созданием ИС;

Е − норма прибыли на капитал (нормативная прибыльность);

П − годовые приведенные затраты на ИС: П=С + ЕК

Единицы измерения в формуле (размерность величин) следующие:

Э − руб./г.; ∆Эгод − руб./г.; С − руб./г., К − руб.; Е − 1/г.; П − руб./г.

Рассмотрим составляющие затрат формулы (1).

Таблица 11 − Затраты до интеграции систем (час)

Вид документа

Время на составление (час)

Количество (шт) на одного сотрудника

Итого времени на обработку (час)

в день

в месяц

в год

в день

в месяц

в год

1

Путевой лист

0,08

130

2 600

31 200

10,4

208

2496

2

Направление ПЛ

0,13

130

2 600

31 200

16,9

338

4056

3

Маршрут

0,03

80

1 600

19 200

2,4

48

576

4

Сопроводительные документы

0,17

30

600

7 200

5,1

102

1224

5

Расписание

8

8

64

6

Отчет

4

14

168

56

672

Таблица 12 − Затраты до интеграции (руб.)

Должность

Документы

З/пл. в час

Итого затраты в год на составление документа

 

1

Диспетчер

1

50

124 800

 

2

Водитель

2,3,4

90

527 040

 

3

Администратор

5

130

8 320

 

Итого:

707 200

 

Таблица 13 − Затраты после введения интеграции (час.)

Вид документа

Время на составление (час)

Количество (шт) на одного сотрудника

Итого времени на обработку (час)

в день

в месяц

в год

в день

в месяц

в год

1

Путевой лист

0,03

130

2600

31200

3,9

78

936

2

Направление ПЛ

0,1

130

2600

31200

13

260

3120

3

Маршрут

0,02

80

1600

19200

1,6

32

384

4

Сопроводительные документы

0,13

30

600

7200

3,9

78

936

5

Расписание

4

4

16

6

Отчет

1

14

168

14

168

Таблица 14 − Затраты после введения интеграции (руб.)

Должность

Документы

З/пл. в час

Итого затраты в год на составление документа

 

1

Диспетчер

1

50

46 800

 

2

Водитель

2,3,4

90

399 600

 

3

Администратор

5

130

2 080

 

Итого:

460 240

 

Годовая экономия ∆Эгод = 707 200– 460 240= 246 960 руб.

С − эксплуатационные затраты на интегрированные системы;

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

(з/пл инженера АС*12мес)*5%=15000*12*0,05 = 9 000 руб./год

(з/пл персонала*12мес)*10%= 460 240*0,1 = 46 024руб./год

Затраты на электроэнергию:

1 компьютер в среднем за час потребляет 0,3 кВт.

Работа компьютера в день – 12 часов.

Тариф за 1 кВт – 2,09 р.

Итого в час: 0,627 р.

Итого за 1 рабочий день: 7,524 р.

Итого за месяц: 225,72 р.

225,72руб.мес.*кол-во раб.мест*12мес = 225,72* 26 * 12мес = =70 424,64 руб./год

прочие расходы = (46 024+ 9 000+70 424,64) * 7% = 8 781,40 руб.

С = 9 000 + 46 024+ 8 781,40+ 70 424,64 = 134 230,04 руб./год

Е – норма прибыли на капитал.

Величина Е в рыночных условиях не должна быть меньше годовой банковской процентной ставки.

Так, если Центральный банк РФ установил с 14сентября 2012г., ставку рефинансирования 8,25%, норму прибыли на капитал необходимо установить равной 8,25%.

К − единовременные затраты (капиталовложения), связанные с созданием ИС;

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

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

Капитальные затраты включают:

  • затраты на техническое обеспечение (вычислительную технику, оргтехнику, средства коммуникации, технические средства охраны и т.п.);

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

  • затраты на обустройство помещений, включая рабочие места служащих;

  • затраты на услуги привлекаемых экспертов и консультантов и т.п.

Согласно плану-графику работ затраты на интеграцию АИС составят 138 976,00руб.

Прочие неучтенные расходы: 138 976,00 * 7% = 9 728,32 руб.

Затраты на техническое и программное обеспечение не требуются, т.к. в Поликлинике №1 имеются необходимая вычислительная техника с установленным ПО и средства коммуникации (табл. 5, Стр. 42).

К = 138 976+ 9 728,32= 148 704,32 руб.

Годовой экономический эффект (экономическая прибыль):

Э = 246 960−134 230,04−148 704,32* 8,25% = 100 461,85 руб.

Таблица 15 − Расчет сроков окупаемости проекта

Год

2013

2014

2015

Номер периода

1

2

янв.

фев.

март

апр.

май

Прибыль

−138 976,00р.

100 461,85р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

Дисконти-рованныйпоток

−138 976,00р.

85 732,47р.

7 097,33р.

7 050,60р.

7 004,18р.

6 958,06р.

6 912,25р.

Кумулятив-ный поток

−138 976,00р.

−53 243,53р.

−46 146,19р.

−39 095,59р.

−32 091,41р.

−25 133,36р.

−18 221,11р.

Год

2015

Номер периода

июнь

июль

авг.

сент.

окт.

нояб.

дек.

Прибыль

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

Дисконти-рованный поток

6 866,73р.

6 821,52р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

8 371,82р.

Кумулятив-ный поток

−11 354,38р.

−4 532,86р.

3 838,96р.

12 210,79р.

20 582,61р.

28 954,43р.

37 326,25р.

Дисконтированный поток:

r – норма прибыли (%) согласно ставке рефинансирования ЦБ = 8,25%

n – период (год)

Рисунок 30. - Кумулятивный поток

Согласно плану-графику затраты на разработку ИС, включая формирования начальной информационной базы и обучение персонала, составят 253 976 руб.

Затраты на техническое обслуживание АИС в течение года и затраты на заработную плату сотрудников, работающих с интегрированными системами составит 254 230,04руб. в год.

Проект окупится через 1 год 8 месяцев.

Выводы по главе 4

В рамках данной главы ВКР было проведено технико-экономическое обоснование разработки и реализации проекта интеграциисистем ИУС «SIKE.Autopark» и системы «КАСУН»на предприятии ООО «Газпром трансгаз Томск», включающее в себя следующие разделы:

1. Расчёт экономических инвестиций на интеграцию систем (проведена оценка затрат на ПО и АО и оценка расходов на использование интегрированных систем, рассчитаны расходы на техническую поддержку АО и ПО и расходы на разработку ПО, расчет стоимости программного продукта).

2. Расчёт экономического эффекта от интеграции АИС, который составил Э= 100 461,85 (руб./год), что указывает на эффективность интеграции систем.

В данной главе был проведен экономический анализ целесообразности интеграции систем на предприятии ООО «Газпром трансгаз Томск». Был разработан план-график, который учитывает этапы проектирования, разработки и внедрения. Реализация выработанного плана-графика займёт 92 рабочих дня, а его стоимость составит 551 170,00 руб.

Предполагаемое время окупаемости проекта составляет 1 года 8 месяцев.

Заключение

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

На данный момент на предприятии существует большой парк автомобильной и специальной техники и ведомственных заправок, которые нуждаются в учете. Данную функцию успешно выполняют системы ИУС «SIKE.Autopark» и система КАСУН. Заказчиком выявлено, что существует ряд бизнес процессов нуждающихся в автоматизации.

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

Автоматизация учета путевых листов посредством интеграции систем ИУС «SIKE.Autopark» и системой КАСУН является оптимальным решением. Оно позволит сэкономить средства и не подвергнет риску работу систем.

  • упростить составление отчетности,

  • уменьшить время обслуживания пациентов,

  • а также исключит возможность потери или дублирования документов.

В рамках данной главы ВКР было проведено технико-экономическое обоснование разработки и реализации проекта интеграции систем ИУС «SIKE.Autopark» и системы «КАСУН» на предприятии ООО «Газпром трансгаз Томск», включающее в себя следующие разделы:

1. Расчёт экономических инвестиций на интеграцию систем (проведена оценка затрат на ПО и АО и оценка расходов на использование интегрированных систем, рассчитаны расходы на техническую поддержку АО и ПО и расходы на разработку ПО, расчет стоимости программного продукта).

2. Расчёт экономического эффекта от интеграции АИС, который составил Э= 100 461,85 (руб./год), что указывает на эффективность интеграции систем.

В данной главе был проведен экономический анализ целесообразности интеграции систем на предприятии ООО «Газпром трансгаз Томск». Был разработан план-график, который учитывает этапы проектирования, разработки и внедрения. Реализация выработанного плана-графика займёт 92 рабочих дня, а его стоимость составит 551 170,00 руб.

Предполагаемое время окупаемости проекта составляет 1 год 8 месяцев.

Список использованных источников
  1. Корнеев Н.В. - Корпоративные информационные системы: Методические указания по выполнению контрольной и курсовой работы для студентов специальности 08081 «Прикладная информатика (в экономике) Н.В.Корнеев.-Тольятти.: ТФ ИКиП,2009.-35с.

  2. Смирнова Г.Н., Сорокин А.А., Тельнюв Ю.Ф. Проектирование экономических информационных систем, - М: Финансы и статистика, 2008.

  3. Елиферов В.Г., Репин В.В. Бизнес процессы: регламентация и управление., - М: ИНФРА-М, 2009.

  4. Калянов Г.Н., Теория и практика реорганизации бизнес процессов. - М., СИНТЕГ, 2009.

  5. Грекул В. И.; Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем : курс лекций: учебное пособие. М.: Интернет-Ун-т Информ. технологий, 2010

  6. Фуфаев Э.В., Фуфаев Д.Э. Базы данных: учебное пособие для студ. сред. проф. образования. - М.: Издательский центр «Академия», 2011.-320 с.4.Ю. Избачков, В. Петров, А. Васильев, И. Телина Информационные системы 3-е издание. - СПб.: Питер, 2010. - 544 с.

  7. Гагарина Л.Г., Киселев Д.В., Федотова Е.Л. Разработка и эксплуатация автоматизированных информационных систем: учебное пособие.-М.: ИД «Форум»: ИНФРА-М, 2008. - 384 с.

  8. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. Пособие. - М.: «Форум»: ИНФРА-М, 2008.-400 с.

  9. http://www.rugost.com/ - Сайт содержит ГОСТы, примеры разработанных документов по ГОСТ (ТЗ, ТП,РД), шаблоны документов по ГОСТ.

  10. География мировых природных ресурсов. Режим доступа: http://do.gendocs.ru/docs/index-347419.html?page=6

  11. Компания "Регионинфо ".Комплексная автоматизированная система управления нефтепродуктообеспечением (КАСУН). Режим доступа: http://www.regioninfo.ru/razrabotka-po/kasun

  12. Компания "Корпоративные системы". Информационно-аналитическая система SIKE.АВТОПАРК. Режим доступа: http://sike.ru/autopark

  13. ГОСТ Р ИСО/МЭК 15271-98 «Информационные технология. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

  14. ГОСТ Р 7.0.5-2009 Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления.

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

  16. ГОСТ 34.321- 96 Информационная технология. Система стандартов по базам данных. Эталонная модель.

  17. Корпоративный менеджмент [Электронный ресурс]: Управление общей стоимостью владения КИС.− Электрон. текстовые дан. – Режим доступа: http://www.cfin.ru

  18. Пятков М. Экономика информационных технологий [Текст]: для экономистовМ. Пятков– М., 2012

  19. Цыгалов Ю. [Электронный ресурс]: Экономическая эффективность инвестиций в ИТ: оптимальный метод оценки.− Электрон. текстовые дан. – Режим доступа: http://www.cfin.ru

  20. ГОСТ Р ИСО/МЭК 12207-09 Информационная технология. Процессы жизненного цикла программных средств.

  21. ГОСТ Р 7.0.5-2008 Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления.

  22. Корпоративные хранилища данных. Интеграция систем. Проектная документация. [Электронный ресурс]. URL: http://www.prj-exp.ru/about. (дата обращения: 15.11.2013).

  23. Ипатова, Э. Р. Практикум по проектированию информационных систем / Э. Р. Ипатова, Ю. В. Ипатов – Магнитогорск :МаГУ, 2009. – 113 с.

  24. Мальковец,М.. Вычисление и оценка показателей деятельности ЛПУ: Методическая разработка /М. Мальковец, Г. Зелезинская, Л. Плахотя– Мн.: МГМИ, 1996.

  25. ГОСТ 24.103-84 «Автоматизированные системы. Основные положения».

  26. ГОСТ 24.104-85 «Автоматизированные системы. Общие требования».

  27. ГОСТ 34.003-90Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.

  28. ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем.

  29. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.

  30. ГОСТ 34.602-89 «Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

  31. ГОСТ Р 50922-96. Защита информации. Основные термины и определения.

  32. ГОСТ Р 51275-99. Защита информации. Объект информации. Факторы, воздействующие на информацию. Общие положения.

  33. ERP-системы: прошлое, настоящее и будущее. ‒ Режим доступа: http://www.intertrust.ru/analytics/we_in_smi/405/

  34. ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств.

  35. ГОСТ Р 7.0.5-2008. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления.

ПРИЛОЖЕНИЯ

Приложение А

Модель AS-IS диаграмма eEPC методологии Aris

ПРИЛОЖЕНИЕ Б

Отчет по контекстной диаграмме (в нотации DFD)

Рисунок 9 – контекстная диаграмма

Рисунок 10 – Декомпозиция контекстной диаграммы

ПРИЛОЖЕНИЕ В

Диаграмма eEPC- Схема передачи данных из центральной базы предприятия в базы филиалов

ПРИЛОЖЕНИЕ Г

Алгоритм передачи данных о фактах заправки

ПРИЛОЖЕНИЕ Д

Алгоритм передачи данных о заправочных станциях

ПРИЛОЖЕНИЕ Е

План график проекта по интеграции

ПРИЛОЖЕНИЕ Ё

План график проекта по интеграции

ПРИЛОЖЕНИЕ Ж

Общая схема обмена данными между ИУС «SIKE.Autopark» и системой КАСУН

ПРИЛОЖЕНИЕ З

Результаты проверки курсовой работы на программе eTXTАнтиплагиат

ПРИЛОЖЕНИЕ И

Рисунок 15. - Занятость ресурсов в проекте

Рисунок 16. - Занятость ресурсов в проекте (продолжение)

Рисунок 17. - Занятость ресурсов в проекте (продолжение)

Рисунок 18. - Время выполнения проекта

Рисунок 19. - Базовая стоимость проекта

Рисунок 2– Фактические данные длительности

Рисунок 2 – Фактические затраты

Рисунок 2 – Освоенный объем

Рисунок 20. - Настройка фильтра

ПРИЛОЖЕНИЕ К

Рисунок 28. - Использование ресурсов

Рисунок 29. - Использование задач

1

Просмотров работы: 2421