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

Введение

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

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

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

• возможность быстрого доступа к любым данным;

• возможность быстрого формирования отчетов;

• экономия трудозатрат и затрат времени на обработку информации.

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

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

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

Цель курсовой работы: разработать ТЗ на внедрение функционального модуля по учету заявок CRM-системы «Охранное предприятие» в ООО ОП «Каскад – С» для оптимизации работы диспетчерского отдела.

Для достижения цели необходимо решить следующие задачи:

1. Проанализировать диспетчерский отдел, описать основные бизнес-процессы ООО ОП «Каскад - С», построить модель “as-is”(как есть);

2. Выявить «узкие» места ООО ОП «Каскад - С» и сформировать предложения по их совершенствованию. Сформировать требования пользователей к информационной системе;

3. Рассчитать экономическую эффективность проекта;

4. Создать ТЗ на внедрение функционального модуля по учету заявок CRM-системы «Охранное предприятие».

В курсовой работе в качестве методологии проектирования использовались методологии структурного анализа и проектирования ARIS. В рамках данных методологий основными инструментальными средствами является Case-средство MS Visio (EPS Diagram, Organization Chart Diagram – организационная диаграмма и Fault Tree Analysis Diagram – диаграмма «Дерево отказов»).

Глава 1. Технико-экономическая характеристика диспетчерского отдела ООО ОП «Каскад-С» Характеристика диспетчерского отдела и построение модели «как есть (as-is)» бизнес-процессов

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

Охранное предприятие «Каскад-С» основано в январе 1996 года. Офис компании находится по адресу: пр. Ленина, д. 68 оф. 336, Магнитогорск, 455044, Россия.

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

Клиентами ООО ОП «Каскад - С» являются как предприятия крупного, так и предприятия среднего и малого бизнеса, а также физические лица.

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

Основными целями деятельности «Каскад - С» являются:

• Получение максимальной прибыли при минимальных издержках;

• Повышение качественного обслуживания;

• Наиболее полное и качественное удовлетворение потребностей;

• Завоевание новых сегментов рынка.

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

Организационная структура ОП «Каскад - С» представлена на рисунке 1.

Рисунок 1- Организационная структура ООО ОП «Каскад - С»

Организационная структура построена с помощью инструментального средства MS Visio.

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

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

Основными функциями диспетчерского отдела являются:

• ведение клиентской базы;

• контроль и обработка сработок;

• ведение табеля учета времени сотрудников;

• ведение журнала заявок.

На успешное функционирование предприятия влияет целый ряд факторов, которые можно подразделить на внутренние и внешние. Все эти факторы отражены на диаграмме Исикавы, представленной на рисунке 2.

В анализе внутренней среды выделяют следующие факторы:

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

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

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

На предприятие влияет также внешняя среда. Различают факторы прямого воздействия и косвенного воздействия внешней среды.

• Факторы прямого воздействия:

•  

  • законодательство;

  • поставщики;

  • конкуренты;

  • потребители;

  • профсоюзы.

• Факторы косвенного воздействия:

•  

  • состояние экономики;

  • научно-технический прогресс;

  • политика;

  • социально-культурный фактор;

  • международный фактор.

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

Рисунок 2- Диаграмма Исикавы в MS Visio

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

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

Используя методику «будет/не будет», определим, какие объекты и процессы будут принадлежать нашей предметной области.

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

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

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

• проект будет предназначен для диспетчера и руководства предприятия;

• проект будет использоваться другими службами: например, бухгалтерским отделом и отделом договоров, руководителем ОП;

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

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

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

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

• проект не предусматривает проблемы оплаты заказанных услуг;

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

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

Основной функцией является – заполнение журнала заявок, а именно оформление заявки клиента, проверка состояния заявки, закрытие заявки, составление отчетности.

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

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

Для наглядного представления работы диспетчерского отдела рассмотрим диаграмму потока работ ARIS EPS. (Рисунок 3).

Рисунок 3- Диаграмма EPC

В ходе анализа системы были выделены следующие «узкие» места:

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

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

• Трудоемкое заполнение журнала заявок;

• Отсутствие единой системы отчетности.

Существует две концепции для устранения «узких» мест:

1. Разработка новой автоматизированной системы.

2. Приобретение и внедрение готовой автоматизированной системы.

Мы предлагаем руководству ООО ОП «Каскад - С» внедрить на своё предприятие CRM-систему «Охранное предприятие». На рынке IT-услуг существует множество небольших автоматизированных систем для охранных предприятии, а CRM-система объединяет в себе весь функционал этих систем. Внедрение системы необходимо осуществлять поэтапно, начиная с внедрения, на наш взгляд, одного из главных модулей - модуля «Журнал Заявок». В дальнейшем будет автоматизирован деятельность диспетчерского отдела и всего предприятия в целом.

Формирование требований пользователя к новой системе

Для начала ознакомимся с предлагаемой системой. CRM-система «Охранное предприятие» - это система управления взаимоотношения с клиентами, является эффективным инструментом для автоматизации охранных предприятий.

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

Модули CRM-системы «Охранное предприятие представлены на рисунке 4.

Рисунок 4- Модули CRM-системы «Охранное предприятие»

Основные характеристики:

• База данных охраняемых объектов и квартир (включая контакты, пароли, приборы, планы, закрепленность за инспекторами и техниками, хранение копий документов), автоматический расчет условных установок, емкость пультов, архивы;

• База данных договоров на монтаж;

• Расчет приложений и счетов за охрану объектов, печать бухгалтерских документов;

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

• Аналитика, отчеты, шаблоны документов представлены в форматах MS Word, MS Excel и FastReport;

• Гибкие права доступа для каждого пользователя;

• Журнал событий;

• Архитектура клиент-сервер на базе бесплатного сервера баз данных Firebird 2.x;

• Внутренние шаблоны документов;

• Рассылка SMS и электронной почты клиентам ОП;

• Журнал заявок;

• Редактор планов объектов и квартир;

• Заявки и договоры на монтаж;

• Маркетинг охранного предприятия – управление сделками.

Мы предлагаем внедрить данную систему поэтапно, начиная с деятельности главного звена предприятия - диспетчерского отдела и в первую очередь внедрить такой модуль как «Журнал заявок», в дальнейшем будут внедрены все модули CRM-системы «Охранное предприятие».

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

Пользователем модуля «Журнал заявок» анализируемой системы является диспетчер предприятия. Система должна взаимодействовать с отделом договоров и руководством предприятия.

Во время обследования объекта информатизации были выделены следующие требования пользователя системы:

• оформление заявки;

• регистрация заявки в журнале заявок;

• проверка текущего состояния заявки;

• отслеживание закрытия заявки клиента;

• закрытие заявки;

• составление отчетности.

На основе полученных данных была построена диаграмма вариантов использования информационной системы для диспетчера предприятия– Use Case Diagram (Рисунок 5). Требования пользователя направлены на устранение “узких мест”.

Рисунок 5. Диаграмма Use-Case. Требования пользователя к системе

Также выделим пользователей проектируемой системы (рисунок 6).

Рисунок 6- Пользователи системы

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

Таблица 1.

Варианты использования пользователей системы

Действующее лицо	Вариант использования (прецедент)
Диспетчер	Осуществляет основные функции модуля учета заявок: оформление заявки; регистрация заявки в журнале заявок; проверка текущего состояния заявки; отслеживание выполнения заявки клиента; закрытие заявки; составление отчетности.
Начальник диспетчерского отдела	Это важное звено предприятия. На основании предоставленного ему отчета из диспетчерского отдела он принимает решения. Начальник диспетчерского отдела имеет доступ ко всей информации диспетчерской.
Технический отдел	Получает от диспетчера информацию о заявке и предоставляет ему информацию о состоянии заявки
Отдел договоров	Сотрудник отдела договоров заключает договор с заказчиком и передает копию договора диспетчеру для учета заявки. Отдел договоров может только просматривать информацию о заказе.

Расчет экономической эффективности проекта

Эффективность системы - это степень ее соответствия своему назначению. Различают экономическую и функциональную эффективность внедрения автоматизированной системы.

Функциональной эффективностью для нашей разработанной системы является то, что администратор выполняет свои основные функции в новой АС.

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

• годовой прирост прибыли;

• годовой экономический эффект;

• расчетный коэффициент экономической эффективности капитальных вложений (срок окупаемости).

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

Используем основной статический показатель экономической эффективности – годовой экономический эффект (экономическая прибыль). Он рассчитывается по формуле:

Э = Эгод – С – ЕК = Эгод – П

где Эгод — годовая экономия (прибыль), вызванная ИС, без учета

эксплутационных затрат на ИС (руб./г.);

С — эксплуатационные затраты на ИС (явные затраты)(руб./г. );

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

Е — коэффициент приведения единовременных затрат к годовым затратам (норма прибыли на капитал или нормативная прибыльность) (1/г.);

П — годовые приведенные затраты на ИС: П=С + ЕК (руб./г.)

(∆Э — С) — это хозяйственная или бухгалтерская прибыль. Она представляет собой разность между выручкой (прибылью) и явными затратами

Произведение ЕК называется неявными затратами (ImplicitCost)

По рыночной терминологии, явные затраты (ExplicitCost) - С — это все денежные издержки предприятия, включая амортизацию.

С точки зрения экономического содержания, величина Е состоит из нормы отдачи на капитал и нормы предпринимательского дохода.

Для начала рассчитаем капитальные затраты на ИС по формуле:

К = Кпр + Ктс + Клс + Кпс + Киб + Куч + Кво + Кпл + Коэ = 12800 + 25 000 + 3 200 + 2 500 + 6 500 + 10 000 + 5 000 + 10000 + 8000 = 83 000

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

В состав эксплуатационных затрат на информационную систему входят следующие затраты:

С = Сзп + Сао + Сто + Спс + Син + Сни + Сэл + Спр = 50 000 + 5000 + 25000 + 10000+ 3500 + 2500 + 5 500 = 101500

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

Произведем расчет годовых приведенных затрат на ИС

Итого получаем:

П=С+Е*К=101500+83000*8,25 % =786250руб.

Произведем расчет прямого экономического эффекта:

где - сокращение заработной платы управленческого персонала при внедрении ИС;

- суммарные эксплуатационные затраты на ИС за исключением заработной платы управленческого персонала.

,

где Сзпб— заработная плата управленческого персонала в базовом варианте;

Сзп — заработная плата управленческого персонала в предлагаемом варианте.

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

П=С+Е*К=101500+83000*8,25 % =78625руб.

Э прям = – С – Е×К=- П

Э прям = -78625руб =0-78625 =-78625руб.

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

В этом случае внедрение ИС целесообразно, только если есть уверенность в достаточно большом косвенном экономическом эффекте.

Косвенный экономический эффект

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

Произведем расчет косвенного экономического эффекта.

Э = ∆Э_год – С – Е×К = ∆Э_год – П = Э_прям + Э_{косв = -} П + Э_косв

Э_косв = DА + DС_себ +DШ,

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

∆А - годовой прирост выручки от реализации продукции =0

∆Ссеб - годовая экономия на себестоимости продукции объекта управления;

∆Ш - сокращение штрафов и других непланируемых потерь за год; Общая сумма штрафов за год, вызванная потерей документов по вине отдела, равна примерно 200000 руб. Функциональный модуль позволит снизить эти потери на 20% в год.

Итого ΔШ=200 000 руб.-(200000руб-20%)=40 000 руб.

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

,

где ∆Ск - экономия на канцелярии;

∆Сэ - экономия на эл. энергии на технологические цели;

∆Сзп - экономия на заработной плате сотрудников;

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

∆Сдок - сокращение потерь документов.

Если внедрение ИС не влияет на какую-либо статью затрат в составе себестоимости, то эта статья, не фигурирует в расчете косвенного экономического эффекта.

В структуре себестоимости основную долю занимают материальные затраты – 40% ; затраты на оплату труда с отчислениями – 34%; прочие затраты – 26% (∆Сэ+∆Ссэо+∆Сдок ).

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

Себестоимость работ - 150000.

Получаем:

∆Ск - экономия на канцелярии

ΔСк=150000*40%-(40%*150000-20%)=12000 руб./мес.;

∆Сзп - экономия на заработной плате сотрудников

ΔСзп=150000*34%-(34%*150000-3%)=1530 руб./мес.;

ΔСпроч=ΔСэ+ΔСсэо+ΔСдок

ΔСпроч=26%*50000-(26%*50000-2%)=780руб/мес.

Таким образом, годовая экономия на себестоимости продукции

ΔСсеб=12*(ΔСк+ΔСзп+ΔСпроч)=12*(12000руб./мес.+ 1530 руб./мес.+ 780 руб/мес) =12*14310руб/мес. =171720руб/год

Таким образом,

Экосв=ΔА+ΔСсеб+ΔШ =0+171720+40000=211720руб.

Эгод=Экосв+Эпрям=211720– 78625=133095 руб.

Годовой экономический эффект - абсолютный показатель эффективности. Т.к. Э>0, то система эффективна.

Вспомогательные показатели экономической эффективности:

Расчетная прибыльность (рентабельность):

Ер=Эгод/К=133095 /83000=1,6

Срок окупаемости:

Ток=1/Ер=К/Эгод=0,8 - проект окупится через 1 месяц.

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

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

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

• охарактеризовано ООО ОП «Каскад - С» в целом, выделены его цели и задачи;

• определены границы по методике «будет/не будет»;

• обследован диспетчерский отдел ООО ОП «Каскад – С»;

• построена модель AS-IS;

• определены и проанализированы узкие места;

• разработано технико-экономическое обоснование;

• определены требования пользователя.

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

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

Рассчитав экономические показатели в технико-экономическом обосновании, был сделан вывод, что внедрение автоматизированной системы будет эффективно.

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

Глава 2. Формирование технического задания на внедрение функционального модуля по учету заявок CRM-системы «Охранное предприятие» в ООО ОП «Каскад - С»

ООО ОП «Каскад-С»

УТВЕРЖДАЮ

 

УТВЕРЖДАЮ:

Директор ООО ОП «Каскад-С»

Личная подпись:

Расшифровка подписи: Селезнев М.В.

Печать

Дата: 02.10.13

УТВЕРЖДАЮ:

Жерикова С.А

Личная подпись:

Расшифровка подписи: Жерикова С.А.

Печать

Дата: 02.10.13

 

Функциональный модуль по учету заявок в охранном предприятии

CRM-система «Охранное предприятие»

наименование вида АС

Диспетчерский отдел ООО ОП «Каскад-С»наименование объекта автоматизации

ФМ «Журнал Заявок»

сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На 40 листах

Действует с 02.10.2013

СОГЛАСОВАНО

Руководитель: начальник диспетчерского отдела

Личная подпись

Расшифровка подписи: Тимшин А.П.

Печать

Дата 02.10.2013

Общие сведения Наименование системы Полное наименование системы

Полное наименование системы – функциональный модуль по учету заявок CRM-системы «Охранное предприятие»

Краткое наименование системы

Краткое наименование – ФМ «Журнал Заявок»

Основания проведения работ

Работа выполняется на основании договора №1 от 02.10.2013 между ООО ОП «Каскад - С» и Жериковой С.А.

Наименование организации – Заказчика и Разработчика Заказчик

Заказчик: ООО ОП «Каскад - С»

Адрес фактический: 455044, г.Магнитогорск, пр.Ленина, д.68 оф.336

Телефон: (3519)26-07-65

Факс: (3519) 26-07-65

Разработчик

Разработчик: Жерикова Светлана Андреевна

Адрес фактический: 455044, г.Магнитогорск, ул.Октябрьская, д.19.

Телефон: +7(3519) 9191191326

Плановые сроки начала и окончания работы

Плановые сроки начала и окончания работ по созданию системы: план-график.

Источники и порядок финансирования

Источники и порядок финансирования указаны в договоре №1. Финансирование работ осуществляет Заказчик.Объем и порядок финансирования определяется Календарным планом работ, Рабочей программой и Протоколом договорной цены, являющихся неотъемлемой частью Контракта (Дополнительных Соглашений) на выполнение работ в соответствии с настоящим Частным техническим заданием.

Порядок оформления и предъявления заказчику результатов работ

Работы по внедрения ФМ «Журнал Заявок» сдаются Разработчиком поэтапно в соответствии с Календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определен Договором.

Назначение и цели создания системы Назначение системы

ФМ «Журнал Заявок» предназначен для диспетчерского отдела ООО ОП «Каскад - С» и будет способствовать:

• Упрощению учета заказа клиентов.

• Отслеживанию состояния и выполнения заказа.

• Интеграции в общую среду информационной системы предприятия.

Цели создания системы

ФМ «Журнал Заявок» разрабатывается для сотрудников диспетчерского отдела с целью:

• Оперативности в обработке документов;

• упрощения обработки заказа клиента;

• создания эффективной системы отчетности;

• повышения качества информации;

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

• упрощения поступления документов из других отделов;

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

Характеристика объектов автоматизации

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

Основными целями деятельности «Каскад - С» являются:

• Получение максимальной прибыли при минимальных издержках;

• Повышение качественного обслуживания;

• Наиболее полное и качественное удовлетворение потребностей;

• Завоевание новых сегментов рынка.

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

Организационная структура ОП «Каскад - С» представлена на рисунке 7. Организационная структура построена с помощью инструментального средства MS Visio.

Рисунок 7- Организационная структура ООО ОП «Каскад - С»

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

Основными функциями диспетчерского отдела являются:

• ведение клиентской базы;

• контроль и обработка сработок;

• ведение табеля учета времени сотрудников;

• ведение журнала заявок.

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

Рассмотрим факторы, которые смогут повлиять на результат работы исследуемого нами отдела. В качестве основной методологии проектирования на данном этапе будем использовать методологиюARIS, диаграмму причин и факторов Исикавы (рисунок 8).

Рисунок 8- Диаграмма Исикавы

В анализе внутренней среды выделим показатели качества и факторы, влияющие на них:

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

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

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

На предприятие влияет также внешняя среда.

• Факторы прямого воздействия:

•  

  • законодательство;

  • поставщики;

  • конкуренты;

  • потребители;

  • профсоюзы.

• Факторы косвенного воздействия:

•  

  • состояние экономики;

  • научно-технический прогресс;

  • политика;

  • социально-культурный фактор;

  • международный фактор.

Далее разработаем событийную цепочку процессов диспетчерского отдела, представленную на рисунке 9.

Рисунок 9- Диаграмма EPC

Событием, инициирующим работу отдела, является «Поступление заявки клиента».

В процессе ведения журнала заявок клиентов можно выделить следующие последовательные функции:

• Обработка заявки клиента.

• Проверка наличия клиента в клиентской базе

• Передача заявки в технический отдел

• Проверка состояния заявки

• Оформление отчета о выполнении заявки

• Закрытие заявки

Завершает работу системы событие «Заявка выполнена». Таким образом, отслеживается весь процесс выполнения заявки.

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

Таблица 2

№	Наименование бизнес-процесса	Возможность автоматизации	Решение об автоматизации в ходе проекта
	Обработка заявки клиента.	Возможна	Будет автоматизирован
	Проверка наличия клиента в клиентской базе	Возможна	Будет автоматизирован
	Передача заявки в технический отдел	Возможна	Будет автоматизирован
	Проверка состояния заявки	Возможна	Будет автоматизирован
	Оформление отчета о выполнении заявки	Возможна	Будет автоматизирован
	Закрытие заявки	Возможна	Будет автоматизирован

Требования к системе Требования к системе в целом Требования к структуре и функционированию системы

Взаимодействие диспетчерского отдела с внешними субъектами представлено на рисунке 10.

Рисунок 10- Взаимодействие диспетчерского отдела с другими отделами

Для каждого пользователя перечислим варианты использования системы (табл.3)

Таблица 3

Варианты использования пользователей системы

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

Система должна поддерживать следующие режимы функционирования:

• Основной режим, в котором ФМ «Журнал Заявок» выполняет все свои основные функции.

• Профилактический режим, в котором ФМ «Журнал Заявок» не выполняет своих функций.

В основном режиме функционирования, Система ФМ «Журнал Заявок» должна обеспечивать:

•  

  1. работу пользователей в режиме – 24 часов в день, 7 дней в неделю (24х7);

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

В профилактическом режиме Система ФМ «Журнал Заявок» должна обеспечивать возможность проведения следующих работ:

• техническое обслуживание;

• модернизацию аппаратно-программного комплекса;

• устранение аварийных ситуаций.

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

Обязательно ведение журналов инцидентов в электронной форме..

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

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

Для поддержки функционирования ФМ «Журнал Заявок» Заказчиком должна быть создана Служба эксплуатации, персонал которой должен обладать знаниями в области информационных технологий. В состав персонала, необходимого для обеспечения эксплуатации комплекса средств автоматизации (КСА) Подсистемы, должны входить:

• Системный администратор;

• Администратор баз данных;

• Администратор информационной безопасности;

• Пользователь.

Основными обязанностями системного администратора являются:

• Модернизация, настройка и мониторинг работоспособности комплекса технических средств (серверов, рабочих станций);

• Установка, модернизация, настройка и мониторинг работоспособности системного и базового программного обеспечения;

• Установка, настройка и мониторинг прикладного программного обеспечения;

• Ведение учетных записей пользователей системы.

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

Основными обязанностями администратора баз данных являются:

• Установка, модернизация, настройка параметров программного обеспечения СУБД;

• Оптимизация прикладных баз данных по времени отклика, скорости доступа к данным;

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

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

Основными обязанностями администратора информационной безопасности являются:

• Разработка, управление и реализация эффективной политики информационной безопасности системы;

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

• Осуществление мониторинга информационной безопасности.

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

Пользователи системы должны иметь опыт работы с персональным компьютером на базе операционных систем Microsoft Windows на уровне квалифицированного пользователя и свободно осуществлять базовые операции в стандартных Windows.

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

Рекомендуемая численность для эксплуатации ФМ «Журнал Заявок»: - Администратор – 1 штатная единица; - Пользователь – число штатных единиц определяется структурой предприятия.

Параметры, характеризующие степень соответствия системы назначению

1.  
   1.  
      1.  

         1. Требования к приспособляемости системы к изменениям

Обеспечение приспособляемости системы должно выполняться за счет:

• своевременности администрирования;

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

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

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

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

• При изменении количества потребителей информации;

• При изменении требований к системе безопасности;

• При изменении количества поставщиков информации.

Влияние изменения количества потребителей информации

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

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

2. Распределение нагрузки между фронтальными серверами должно автоматически выравниваться.

3. Добавление новых фронтальных серверов не должно приводить к полной или частичной остановке функционирования.

Влияние изменения требований к системе безопасности.

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

1. В процессе адаптации защищенность не должна становиться хуже существующей на момент начала адаптации.

2. Процесс адаптации не должен прерывать доступа потребителей информации к информационным ресурсам.

3. Процесс адаптации не должен прерывать процесс подготовки и публикации документов.

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

1.  
   1.  
      1.  

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

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

Таблица 3

Требования к сохранению работоспособности

Вероятное условие	Требование
Нарушения в работе системы внешнего электроснабжения серверного оборудования продолжительностью до 15 мин.	Приостановка работы ФМ «Журнал Заявок»
Вероятное условие	Т Продолжение таблицы 3 ребование
Выход из строя сервера подсистемы хранения данных	Уведомление администратора

1.  
   1.  
      1. Требования к надежности

         1. Состав показателей надежности для системы в целом

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

Надежность должна обеспечиваться за счет:

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

• своевременного выполнения процессов администрирования Системы;

• соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

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

Время устранения отказа должно быть следующим:

• при перерыве и выходе за установленные пределы параметров электропитания - не более 5 минут.

• при перерыве и выходе за установленные пределы параметров программного обеспечением - не более 1 часа.

1.  
   1.  
      1.  

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

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

• сбой в системе электроснабжения аппаратной части;

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

• ошибки, связанные с программным обеспечением (ОС и драйверы устройств).

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

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

При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

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

Требования к эргономике и технической эстетике

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

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

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

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

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

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

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

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

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Система должна быть рассчитана на эксплуатацию в составе программно–технического комплекса Заказчика и учитывать разделение IT-инфраструктуры Заказчика на внутреннюю и внешнюю.

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

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

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

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

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

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

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

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

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

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

Все пользователи системы должны соблюдать правила эксплуатации электронной вычислительной техники.

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

Требования к защите информации от несанкционированного доступа

1.  
   1.  
      1.  

         1. Требования к информационной безопасности

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

• Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.

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

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

• Разграничение прав доступа пользователей и администраторов Системы должно строиться по принципу, что не разрешено, то запрещено и т.д.

• Система должна обеспечивать обработку конфиденциальной информации.

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

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

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

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

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

1.  
   1.  
      1.  

         1. Требования к антивирусной защите

Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы. Средства антивирусной защиты рабочих мест пользователей и администраторов должны обеспечивать:

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

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

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

• ведение журналов вирусной активности;

• администрирование всех антивирусных продуктов.

Требования по сохранности информации при авариях

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

Требования к защите от влияния внешних воздействий

К программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий:

1. требования к радиоэлектронной защите:

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

1. требования по стойкости, устойчивости и прочности к внешним воздействиям:

• система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265В (220 ± 20 % - 30 %);

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

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

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

Требования по стандартизации и унификации

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

В качестве методологии проектирования используются методологии структурного анализа и проектирования SADT и ARIS. В рамках данных методологий основными инструментальными средствами являются AllFusion Process Modeler (Bpwin), AllFusion Data Modeler (ERwin) (IDEF1X), а также Case-средство MS Visio (EPS Diagram, Cause and Effect Diagram – «Диаграмма Исикавы», Organization Chart Diagram – организационная диаграмма).

Для работы с БД должны использоваться язык запросов SQL в рамках стандарта ANSI SQL. В системе должны использоваться общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

Дополнительные требования

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

Требования безопасности

Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).

Требования к транспортабельности для подвижных АИС

Система является стационарным и после монтажа и проведения пуско-наладочных работ транспортировке не подлежит.

Требования к структуре и функциям системы

Бизнес – требования:

Исходные данные, возможности бизнеса и нужды клиента:

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

Бизнес - цели и критерии успеха:

Бизнес – цель 1. Уменьшить среднее рабочее время диспетчера обслуживание клиента до 10 минут.

Бизнес - цель 2. Увеличить скорость взаимодействия с другими отделами (отдел договоров, руководитель, технический отдел).

Бизнес – цель 3. Организовать эффективную систему отчетности.

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

Критерий успеха 2. Создание локальной сети для эффективного взаимодействия между отделами.

Факторы бизнес – риска:

Фактор бизнес – риска 1. Не все диспетчеры готовы к работе с ФМ «Журнал заявок». Потребуются финансовые и временные ресурсы на обучение персонала.

Фактор риска 2. Нововведения частично зависят и от других отделов

Образ решения

Положение об образе проекта.

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

На рисунке 11 представлены варианты использования информационной системы для пользователя (диспетчера).

Рисунок 11. Диаграмма Use-Case. Требования пользователя к системе

Таблица 4

Варианты использования для пользователя

Действующее лицо	Вариант использования (прецедент)
Диспетчер	Осуществляет основные функции модуля учета заявок: Оформление заявки клиента. Регистрация заявки в журнале Проверка состояния заявки Составление отчетности Закрытие заявки

1.  
   1.  
      1. Перечень функций или задач, подлежащих автоматизации

Таблица 5

Функции и задачи, подлежащие автоматизации

Функция	Задача
Заполнение журнала заявок	Оформление заявки Регистрация заявки в журнале Закрытие заявки
Проверка текущего состояния заявки	Составление запроса на предоставление информации о статусе заявки
Составление отчетности	Составление отчетности

1.  
   1.  
      1. Временной регламент реализации каждой функции

Таблица 6

Временной регламент реализации задач

Функция	Задача
Оформление заявки	Регулярно, в зависимости от заявок клиентов
Регистрация заявки в журнале	Регулярно, в зависимости от заявок клиентов
Закрытие заявки	Регулярно, в зависимости от заявок клиентов
Составление запроса на предоставление информации о статусе заявки	Регулярно, в зависимости от заявок клиентов
Составление отчетности	Весь период функционирования системы

1.  
   1.  
      1. Разработка прототипа системы

К прототипу, проясняющего и завершающего процесс формулировки требований к системе, относится модель TO-BE. На этом этапе моделируются новые функции и потоки данных, которые появятся в результате внедрения АИС. Разработаем диаграмму EPС (рисунок 12)

Отличие данной модели от представленной выше модели «as-is» состоит в том, что документооборот происходит не в ручную, а автоматизировано. Кроме того, нет необходимости отправлять какие-либо документы в другие отделы, поскольку данные отделы сами смогут обратиться к ИС. Так же установлена связь с техническим отделом.

Рисунок 12- Диаграмма EPC «to-be»

Требования к видам обеспечения Требования к математическому обеспечению

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

Требования к информационному обеспечению

1.  
   1.  
      1.  

         1. Требования к составу, структуре и способам организации данных в системе

Структура хранения данных в системе должна состоять из следующих основных областей:

• область временного хранения данных;

• область постоянного хранения данных;

• область витрин данных.

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

1.  
   1.  
      1.  

         1. Требования к информационному обмену между компонентами системы

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

Таблица 7

Требования к информационному обмену

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

1.  
   1.  
      1.  

         1. Требования к информационной совместимости со смежными системами

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

1.  
   1.  
      1.  

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

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

1.  
   1.  
      1.  

         1. Требования по применению систем управления базами данных

Для реализации подсистемы хранения данных должна использоваться промышленная СУБД.

1.  
   1.  
      1.  

         1. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

1.  
   1.  
      1.  

         1. Требования к контролю, хранению, обновлению и восстановлению данных

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

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

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

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

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

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

• для сервера базы данных необходимо обеспечить резервное копирование его бинарных файлов раз в 2 недели и хранение копии на протяжении 2-х месяцев;

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

  • холодная копия - ежеквартально;

  • логическая копия - ежемесячно (конец месяца);

  • инкрементальное резервное копирование - еженедельно (воскресение);

  • архивирование - ежеквартально;

1.  
   1.  
      1.  

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

Требования не предъявляются.

1.  
   1.  

      1. Требования к лингвистическому обеспечению

Лингвистическое обеспечение должно включать:

• языковые средства общения пользователей с системой;

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

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

Языковые средства системы должны обеспечивать:

• технологическое единство в рамках системы, отдельных подсистем;

• поиск информации в документах системы;

• достижение максимальных характеристик по полноте и точности при поиске информации в системе;

• развитую систему диалога на языке, близком к естественному;

• формирование и выдачу информации, а также ее отображение с учетом принципов «дружественного интерфейса».

1.  
   1.  

      1. Требования к программному обеспечению

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

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

В качестве методологии проектирования используются методологии структурного анализа и проектирования SADT и ARIS. В рамках данных методологий основными инструментальными средствами являются AllFusion Process Modeler (Bpwin), AllFusion Data Modeler (ERwin) (IDEF1X), а также Case-средство MS Visio (EPS Diagram, Cause and Effect Diagram – «Диаграмма Исикавы», Organization Chart Diagram – организационная диаграмма).

Данные получаемые в ходе работы с системой, хранятся и обрабатываются при помощи Microsoft SQL Server. Основной используемый язык запросов — Transact-SQL.

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

К обеспечению качества программных средств (ПС) предъявляются следующие требования:

• функциональность должна обеспечиваться выполнением подсистемами всех их функций.

• надежность должна обеспечиваться за счет предупреждения ошибок - не допущения ошибок в готовых ПС;

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

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

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

• также на каждом этапе в разработки ПС должна проводиться проверка правильности принятых решений по разработке и применения готовых ПС.

Необходимость согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ отсутствует.

Интерфейс системы

Представим интерфейс внедряемого модуля «Журнал заявок»

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

Визуальное представление интерфейса продемонстрировано ниже (рис.13 – рис.16).

Рисунок 13. Запуск «Журнала Заявок»

Рисунок 14. Главная форма «Журнал заявок»

Рисунок 15. Форма Работа с заявкой

Рисунок 16. Операции по заявке

Рисунок 15. Список операций работы с заявкой

Рисунок 16. Закрытие заявки

1.  
   1.  

      1. Требования к техническому обеспечению

Специальные требования к техническому обеспечению отсутствуют

1.  
   1.  

      1. Требования к метрологическому обеспечению

Не предъявляются.

1.  
   1.  

      1. Требования к методическому обеспечению

Не указывается.

1.  
   1.  

      1. Требования к патентной чистоте

По всем техническим и программным средствам, применяемым в системе должны соблюдаться условия лицензионных соглашений и обеспечиваться патентная чистота. Состав и содержание работ по созданию системы Данный раздел должен содержать перечень стадий и этапов работ по созданию системы в соответствии с в соответствии с ГОСТ 24.601. Разработаем в среде MS Project следующие документы: план и длительность проекта (рис.17), график выполнения проекта (рис.18), лист ресурсов (рис.19)

Рисунок 17- План и длительность проекта

Рисунок 18- График выполнения проекта

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

Порядок контроля и приемки системы

Общие требования к приемке работ.

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

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

Испытания Подсистемы должны проводиться в соответствии с ГОСТ 34.603-92.

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

Этап «Проведение предварительных испытаний» заканчивается оформлением акта о приемке Подсистемы в опытную эксплуатацию с приложением к нему протоколов испытаний.

Результаты работ по этапу «Опытная эксплуатация» принимаются с оформлением Акта о завершении опытной эксплуатации.

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

Порядок и сроки проведения приемочных испытаний определяются Заказчиком на этапе «Опытная эксплуатация».

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

Виды и объем испытаний системы

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

1.  

   1. Предварительные испытания.

   2. Опытная эксплуатация.

   3. Приемочные испытания.

Состав испытаний

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

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

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

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

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

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

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

Приемочные испытания должны включать проверку:

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

• выполнении каждого требования, относящегося к интерфейсу Подсистемы;

• работы персонала в диалоговом режиме;

• средств и методов восстановления работоспособности Подсистемы после отказов;

• комплектности и качества эксплуатационной документации.

Проверку работы персонала в диалоговом режиме проводят с учетом полноты и качества выполнения функций Подсистемы в целом. При этом проверке подлежат:

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

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

• реакция Подсистемы и ее частей на ошибки оператора, средства сервиса.

Проверка средств восстановления работоспособности Подсистемы после отказов ЭВМ должна включать:

• проверку наличия в эксплуатационной документации рекомендаций по восстановлению работоспособности и полноту их описания;

• практическую выполнимость рекомендованных процедур;

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

При испытаниях Подсистемы проверяется:

• качество выполнения комплексом программных и технических средств автоматических функций во всех режимах функционирования Подсистемы согласно ЧТЗ

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

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие

В ходе выполнения проекта на объекте автоматизации требуется выполнить работы по подготовке к вводу системы в действие. При подготовке к вводу в эксплуатацию ФМ «Журнал Заявок» Заказчик должен обеспечить выполнение следующих работ:

1. Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации ФМ «Журнал Заявок»

2. Обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;

3. Обеспечить соответствие помещений и рабочих мест пользователей системы в соответствии с требованиями, изложенными в настоящем ЧТЗ;

4. Обеспечить выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение ФМ «Журнал Заявок»;

5. Совместно с Исполнителем подготовить план развертывания системы на технических средствах Заказчика;

6. Провести опытную эксплуатацию ФМ «Журнал Заявок».

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

Требования к документированию

По желанию заказчика разработчик системы может произвести детальное описание принципа функционирования системы. Требования к документированию:

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

• требования по документированию комплектующих элементов;

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

Вся работа по внедрению ФМ «Журнал Заявок» должна быть документирована в соответствии со стандартами. Перечень стандартов и базовых нормативных документов для выполнения проекта приведен ниже:

1. ГОСТ 34.602 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

2. РД 50-34.698-90 Автоматизированные системы требования к содержанию документов.

3. ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла ПС.

4. ISO 15504:1-9:1998 Оценка (аттестация) процессов жизненного цикла программных средств

5. ISO 15271:1998. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207.

6. ISO 16326:1999. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.

7. ISO 9000-3:1997. Стандарты в области административного управления качеством и обеспечения качества. Часть 3. Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.

8. ГОСТ 19-201-78 Единая система программной документации. Техническое здание. Требование к содержанию и оформлению.

9. ГОСТ 19.402-78 Единая система программной документации. Описание программы.

10. ГОСТ 19.404-79 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению.

11. ГОСТ 19.301-79 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению.

Источники разработки

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

• Договор №1 от 20.11.2012 между ООО ОП «Каскад -С» и Жериковой С.А.

• ГОСТ 24.701-86 “Надежность автоматизированных систем управления”.

СОСТАВИЛИ

Наименование организации	Должность исполнителя	Фамилия имя, отчество	Подпись	Дата

СОГЛАСОВАНО

Наименование организации	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата

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

Во второй главе данного проекта было составлено ТЗ на внедрение функционального модуля по учету заявок CRM-системы «Охранное предприятие» в ООО ОП «Каскад – С»

В ТЗ были отражены следующие моменты:

• Общие сведения об информационной системе ФМ".

• Назначение и цели создания системы.

• Характеристика объектов автоматизации.

• Требования к системе.

• Состав и содержание работ по созданию системы

• Порядок контроля и приемки системы.

• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

• Требования к документированию.

• Источники разработки.

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

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

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

• Трудоемкое заполнение журнала заявок.

• Отсутствие единой системы отчетности.

Заключение

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

Во время работы были сформированы требования к новой автоматизированной системе, разработана концепция информационной системы и сформировано ТЗ.

Для реализации обозначенных ранее задач был использован метод анкетирования, анкету заполнял начальник диспетчерского отдела Тимшин А.П.; так же использовались следующие методологии структурного анализа и проектирования: SADT, RUP и ARIS.

Были построены модели:

1. Organization Chart Diagram – организационная диаграмма (MS Visio);

2. Effect Diagram – «Диаграмма Исикавы» (MS Visio);

3. eEPC Diagram – диаграмма потока работ (MS Visio);

4. функциональная диаграмма IDEF0 (AllFusion Process Modeler);

5. диаграмма потоков данных – DFD (AllFusion Process Modeler);

6. Use Case Diagram – диаграмма вариантов использования (Rational Rose);

7. IDEF1X (AllFusion Data Modeler).

Были сделаны выводы о том, что в деятельность ООО ОП «Каскад - С» необходимо внедрить CRM-систему «Охранное предприятия», начиная с внедрения одного из главных ее функциональных модулей – «Журнал Заявок» .

В рамках данного проекта было разработано ТЗ функционального модуля по учету заявок в диспетчерском отделе ООО ОП «Каскад - С». Поставленная вначале цель была достигнута.

Для достижения желаемого результата были выполнены следующие задачи:

• Анализ диспетчерского отдела ООО ОП «Каскад – С».

• Построение модели “as-is” бизнес-процессов деятельности диспетчерского отдела ООО ОП «Каскад – С».

• Определение “узких мест”.

• Формулировка требований пользователей к информационной системе.

• Расчет экономической эффективности проекта.

• Разработка модели “to-be” бизнес-процессов деятельности диспетчерского отдела.

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

• Определение состава и содержание работ по созданию системы.

• Составление технического задания проекта.

На базе разработанного в данной работе ТЗ функционального модуля по учету заявок на ОП «Каскад – С» возможно создание информационной системы для диспетчерского отдела и предприятия в целом.

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

1. ГОСТ 24.202-80. Информационная технология. Комплекс стандартов на автоматизированные системы. Требования к содержанию документа «Технико-экономическое обоснование создания АСУ».

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

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

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

5. ГОСТ 34.602-89 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

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

9. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.

10. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие / А.М. Вендров. – М.: Финансы и статистика, 2004. 192 с.

11. Ипатова Э.Р. Проектирование информационных систем: Учеб.пособие / Ипатова Э.Р, Ипатов Ю.В.. – Магнитогорск: МаГУ,2005. – 187 с.

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

13. Калянов Г.Н. Консалтинг при автоматизации предприятий (подходы, методы, средства) / Г.Н. Калянов. - М.: СИНТЕГ, 1997. – 316 с.

14. Копылов И.П. Справочник по электрическим машинам / И.П. Копылов, Б.К. Клоков – М.: ЭНЕРГОАТОМИЗДАТ, 1988. – 550 с.

15. Липаев В.В. Системное проектирование сложных программных средств для информационных систем / В.В. Липаев. - М.: СИНТЕГ, 1999. - 530с.

16. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0 / С.В. Маклаков. – М.: ДИАЛОГ-МИФИ, 2002. – 224 с.

17. Методика определения экономической эффективности автоматизированных систем управления предприятиями и производственными объединениями / ГКНТ СССР. АН СССР. – М.: Статистика, 1979.- 62 с.

18. Иорш В.И. Основные фонды: от учета к эффективному управлению/ В. И. Иорш, В. Д. Стружинский // Корпоративные системы. – 2005. - №3. – С. 24 – 25.

19. Иорш В.И. Управление основными фондами на основе ключевых показателей эффективности / В. И. Иорш, В. Д. Стружинский // Горный журнал. – 2005. - №3. – С. 25 – 28.

20. Скрипкин К. Экономика информационных систем: от снижения затрат к повышению отдачи / К. Скрипкин // Директор информационной службы. – 2003. - № 6.

21. Видяпина В.И. Показатели и пути улучшения использования основных фондов предприятия / В.И. Видяпина. - Режим доступа: http://www.prostoev.net/modules/myarticles/article.php?storyid=29

Приложения

Приложение А

Анкета

1. Название подразделения: диспетчерский отдел;

2. Фамилия, имя, отчество начальника: Тимшин Александр Петрович, телефон: 8-908-574-11-08;

3. Основная цель диспетчерского отдела: обеспечение связи между клиентом и предприятием;

4. Основные функции диспетчерского отдела: контроль, прием заявок, учет рабочего времени сотрудников, ведение клиентской базы;

5. Кадровый состав диспетчерского отдела: диспетчер, начальник диспетчерского отдела.

6. Документы, поступающие в диспетчерский отдел из других подразделений:

• Копия договора – из отдела договоров

• Документ, содержащий информацию о состоянии заявки – из технического отдела

1. Физическое представление, время и частота поступления, вид обработки и требования к безопасности каждого из этих документов:

• Копия договора – бумажный документ, поступает из отдела договоров, впоследствии анализируется диспетчером;

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

1. Продолжительность хранения каждого из документов и условия перевода в архив:

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

• Копия договора - не хранится в диспетчерском отделе.

1. Документы, формирующиеся в диспетчерском отделе: журнал заявок, отчет;

2. Физическое представление время, частота и вид обработки и требования к безопасности каждого из этих документов:

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

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

1. Продолжительность хранения каждого из документов и условия перевода в архив:

• Журнал заявок и отчет хранятся в течение календарного года и по истечению этого срока уничтожаются.

1. Документы, передающиеся в другие подразделения: отчеты- руководителю предприятия.

2. Физическое представление время и частота отправки, вид обработки и требования к безопасности каждого из этих документов:

• Отчеты – бумажный документ, формируется диспетчером, передаются руководителю предприятия.

1. Продолжительность хранения каждого из документов и условия перевода в архив:

• Отчеты хранятся в течении года и по истечению срока уничтожаются.

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

2. Информация, передающаяся из диспетчерского отдела во внешние органы: из диспетчерского отдела во внешние органы информация не поступает.

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

4. Основные недостатки бизнес-процессов и существующей системы обработки документов в диспетчерском отделе: дублирование информации, сложности при работе с бумажными документами.

5. Предложения по реорганизации бизнес-процессов и существующей системы обработки документов в диспетчерском отделе: автоматизировать такие процессы как: ведение журнала заявок.

6. Дата заполнения анкеты: __________________.

7. Подпись: ________________________________.

Приложение Б

Приложение В

Дата _________________

Заявка

______________________________________________

( название услуги)

1. Наименование организации-заказчика

2. Юридический адрес организации-заказчика

1. Контактное лицо заказчика (Ф.И.О.), должность

____________________________________________________________________

5.Контактный телефон, факс_________________________________________

6. Наименование объекта

^{(квартира, магазин, офис, административное здание, частный жилой дом, дом, гараж, др.)}

7. Адрес объекта

11.Желаемый срок исполнения заявки

Приложения

Подпись_______________________

67

Код для цитирования: Скопировать