Меню Услуги

Анализ учета и исполнение заявок ремонта оргтехники

Страницы:   1   2   3


Содержание

 

  • Введение
  • 1 Описание объекта автоматизации
  • 1.1 Отдел технической поддержки ФГУП «Почта России»
  • 1.2 Цели и задачи автоматизации отдела технической поддержки ФГУП «Почта России»
  • 2 Выбор АИС
  • 3 Инструментарий для построения требуемой АИС учёта
  • 3.1 Выбор архитектуры ИС
  • 3.2 Шаблон проектирования
  • 3.3 Реализация хранилища данных
  • 3.4 Каркас приложения
  • 3.5 Web-сервер
  • 4 Моделирование АИС учёта и исполнения заявок ремонта оргтехники
  • 4.1 Моделирование в AllFusion ERwin Process Modeler
  • 4.2 Моделирование в AllFusion ERwin Data Modeler
  • 4.3 Разработка интерфейса АИС УИЗРО
  • 5 Безопасность и экологичность проекта
  • 5.1 Анализ опасных и вредных производственных факторов и мероприятия по обеспечению безопасных и безвредных условий труда
  • 5.1.1 Рабочее место оператора.
  • 5.1.2 Оценка напряженности труда.
  • 5.1.3 Расчет СОИ
  • 5.2 Экологичность проекта
  • 5.3 Устойчивость в ЧС
  • Заключение
  • Список использованных источников

Введение

 

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

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

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

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

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

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

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

 

1 Описание объекта автоматизации

 

Узнай стоимость написания такой работы!

Ответ в течение 5 минут! Без посредников!

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

 

1.1 Отдел технической поддержки ФГУП «Почта России»

 

В данном дипломном проекте в качестве примера предприятия, требующего внедрения АИС, рассматривается Российская федеральная почтовая сеть.

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

«Почта России» сегодня – это 84 филиала, 42 000 объектов почтовой связи, 415 000 сотрудников. Ежегодно почтовые работники России принимают, обрабатывают и доставляют более 1,5 млрд писем, 48 млн посылок и более 190 млн. денежных переводов.

Почта России предлагает своим клиентам свыше 80 почтовых, финансовых, инфокоммуникационных и прочих услуг.

ФГУП «Почта России» было основано в рамках проведения реструктуризации организаций федеральной почтовой связи, направленной на обеспечение гарантированного предоставления универсальных услуг почтовой связи на всей территории Российской Федерации, расширение спектра услуг почтовой связи, создание современной почтовой инфраструктуры.

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

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

  • вычислительная техника (системные блоки ПЭВМ, мониторы, серверы);
  • оргтехника (принтеры, копиры, сканеры);
  • контрольно-кассовые машины, терминалы;
  • сетевое оборудование (коммутаторы, маршрутизаторы);
  • банковское оборудование (счётчики и детекторы банкнот);
  • средства связи (телефоны, модемы).

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

 

1.2 Цели и задачи автоматизации отдела технической поддержки ФГУП «Почта России»

 

В ходе выполнения дипломной работы мной были проведены исследования среди персонала и руководства отдела технической поддержки (ОТП). Проанализировав собранный материал, можно представить текущую структуру процесса функционирования подразделений ФГУП Почта России, в которые вовлечён ОТП (рисунок 1). Принимая решение о внедрении АИС, я буду придерживаться поставленных передо мной целей. Таким образом, цели автоматизации можно сформулировать следующим образом:

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

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

Рисунок 1. – Структурная схема автоматизируемого процесса

 

2 Выбор АИС

 

Рассмотрим, при помощи какой автоматизированной системы можно добиться поставленной цели.

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

Однако внедрение подобной системы является достаточно рискованным процессом по ряду причин, главные из которых – необходимость настройки программы на решение специфических задач конкретного предприятия и необходимость проведения организационных преобразований для адаптации самого учета к системе. Кроме того, если для автоматизации бухгалтерского учета подойдет готовое решение (например, система «1С:Предприятие»), требующее минимальной доработки, то в такой слабо формализованной области, как управленческий учет, возможно, более эффективным решением будет создание уникальной программной системы, максимально удовлетворяющей потребности конкретного предприятия. Чаще всего такое решение будет еще и менее громоздким. Однако при отсутствии удобного инструментария построение подобной системы может потребовать значительных затрат времени.

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

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

Ведущие разработчики пакетов деловых приложений уже особо и не настаивают, чтобы предприятия автоматизировали все свои бизнес-процессы на одном ядре. SAP, например, давно уже сменила концепцию в пользу интеграционной платформы, на которой можно объединять в КИС разнородные приложения. Пожалуй, только Oracle продолжает упорствовать, рекламируя достоинства работы на решениях одного поставщика. ИТ-директора, как люди технические, тоже в большинстве своем сторонники подхода best of breed.

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

Узнай стоимость написания такой работы!

Ответ в течение 5 минут! Без посредников!

Исследования на западном корпоративном рынке показали, что удовлетворительной считается кастомизация на уровне 40% изменений. При этом кастомизацией западные ИТ-директора называют изменения в настройках системы. В России же, как правило, это «глубокая» переделка системы под «настройки» бизнеса, далеко не всегда оправданная. Если такая переделка переваливает за уровень 50%, переделывать систему не имеет смысла: проблема уже в бизнесе».

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

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

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

Рисунок 2 – Доля собственных интеграционных решений

 

Проведя исследование среди существующих автоматизированных информационных систем, можно сделать следующие выводы:

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

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

 

3 Инструментарий для построения требуемой АИС учёта

 

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

  • технологии, основанные на использовании объекто-ориентирован­ных визуальных сред разработки программного обеспечения и встроенных средств управления базами данных (Borland Delphi, Visual C++, Visual Foxpro и т.д.). Данный способ построения системы является зависимым от конкретной платформы разработки, что ограничивает возможности и универсализм в использовании системы, так как обычно приходиться устанавливать дополнительное ПО;
  • Веб-технологии, основанные на использовании гипертекстовых средств с применением «скриптовых» языков (PHP, Perl, ASP, Phyton) в привязке с «сетевыми» СУБД (MySQL, Oracle, PostgreSQL, MS SQL). Этот способ разработки является более универсальным, так как доступ к системе возможен с помощью обычного Веб-браузера;
  • технологии, основанные на Веб-сервисах — Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения. В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.

Рассмотрим подробнее каждый из способов реализации и инструменты, при помощи которых можно воплотить в жизнь то, разрабатываемую АИС.

 


Страницы:   1   2   3