Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

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

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

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

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

а)целенаправленный сбор, первичная обработка и предоставление доступа к информации;

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

в)своевременное получение информации и ее использование для принятия решений.

Основная проблема сбора необходимой информации состоит в том, чтобы обеспечить:

Полноту, адекватность, непротиворечивость и целостность информации;

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

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

Темой дипломного проекта является «Разработка информационной системы «Учет работы с клиентами» на примере ОАО «Кировэнергосбыт»».

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

Объектом исследования является автоматизированная информационная система.

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

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

1)проанализировать предметную область;

2)создать проект информационной системы;

3)изучить и выбрать средства разработки информационных систем;

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

5)разработать информационную систему;

6)описать способ эксплуатации созданной информационной системы;

7)определить перспективы развития созданной информационной системы.

ОБЗОР И АНАЛИЗ НАУЧНО-ТЕХНИЧЕСКОЙ ИНФОРМАЦИИ

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

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

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

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

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

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

Информационными системами, обеспечивающими эффективную ориентацию на рынок, в настоящий момент являются системы класса CRM (customer relationship management - управление взаимоотношениями с клиентами). Customer Relationship Management - современное направление в сфере автоматизации корпоративного управления. Данные системы направлены на создание обширной базы «верных» клиентов, которая как раз и является для предприятия долгосрочным конкурентным преимуществом. Такие системы появились в середине 90-х годов и находятся в стадии развития, поэтому на российском рынке они представлены гораздо в меньшей степени, чем системы ERP (enterprise resources planning - планирование ресурсов предприятия).

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

Они позволяют:

Осуществлять продажи различных услуг и продуктов;

Отвечать на клиентские запросы;

Заниматься маркетингом;

Анализировать ситуацию на рынке.

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

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Анализ предметной области

ОАО «Кировэнергосбыт» имеет длительную историю. Энергосбыт был создан в Соответствии с решением об упорядочении энергосбытовой деятельности приказом Энергокомбината от 02.01.1937 г.

Открытое акционерное общество «Кировэнергосбыт» создано в результате реорганизации ОАО «Кировэнерго» в форме выделения (протокол внеочередного общего собрания акционеров ОАО «Кировэнерго» № 14/В от 02 апреля 2004 г.) и зарегистрировано в качестве юридического лица 01 мая 2005 года. Реорганизация ОАО «Кировэнерго» проводилась в соответствии с основными направлениями государственной политики по реформированию электроэнергетики и Проектом реформирования.

Основными видами деятельности Общества являются:

Покупка электрической энергии на оптовом и розничном рынках электрической энергии (мощности);

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

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

ОАО «Кировэнергосбыт» видит свою миссию в долгосрочной деятельности на оптовом и розничном клиентских рынках по предоставлению потребителям надежного и бесперебойного энергетического снабжения, связанных с ним качественных клиентских сервисов, а также других продуктов и услуг в смежных (сопряженных с энергообеспечением) бизнесах.

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

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

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

Грамотное функционирование отделов позволяет выполнять стоящие перед предприятием задачи.

1)Отдел оптовых закупок электроэнергии и прогнозирования

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

2)Отдел информационного и технического сопровождения

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

3)Отдел информационных технологий

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

4)Цех по ремонту и техническому обслуживанию приборов учёта

Коллектив цеха производит ремонт и техническое обслуживание приборов учёта, производит проверку 30 тысяч однофазных и 9 тысяч трёхфазных счётчиков в год.

5)Юридический отдел

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

6)Договорной отдел

В настоящее время в договорном отделе работает 7 квалифицированных инженеров, в каждом из 9-ти отделений ОАО «Кировэнергосбыт» также имеется инженер по договорам. Клиентская база - более 610 тысяч потребителей электрической энергии.

7)Отдел расчётов

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

8)Отдел распределения и контроля

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

9) Бухгалтерия

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

10) Финансовый отдел

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

11) Планово-экономический отдел

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

12) Отел по работе с потребителями

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

13) Производственно- технический отдел

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

14) Группа корпоративного управления

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

15) Служба внутреннего энергетического контроля

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

16) Отдел по управлению персоналом

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

17) Отдел технического аудита

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

18) Отдел методологии и координации работы

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

19) Группа связи

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

20) Общий отдел

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

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

Инспекция ИТР (инженерно технические работники) ведёт контроль за выполнением договоров, отклонения и ограничения.

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

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

Делопроизводитель занимается делопроизводством на предприятии.

Инженер по учёту проверяет электрические счётчики и контролирует работу электрических монтёров.

Электрические монтёры проверяют и заменяют счётчики.

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

Списочная численность персонала Общества по состоянию на 31 декабря 2012 года составила 698 человек, из них:

руководители - 45 человек;

специалисты - 269 человек;

рабочие - 362 человека;

служащие - 22 человека. (Приложение 4)

Всего за 2012 г. по регулируемым договорам приобретено 1051 млн. кВт*ч электроэнергии по регулируемой цене 560,07 руб/мВт*ч. Объем покупки на конкурентном рынке на сутки вперед по свободным ценам составил 3368,8 млн. кВт*ч по средней конкурентной цене 1001,81 руб/мВт*ч. (Приложение 5)

Объемы продаж электроэнергии ОАО «Кировэнергосбыт» на оптовом рынке в 2012 году составили:

Рынок на сутки вперед - 0, 921 млн. кВт*ч,

Балансирующий рынок - 71,4 млн. кВт*ч. По средней цене 835,28 руб/мВт*ч.

За 2012 год объем продаж электрической энергии составил 12428,7 млн. руб., фактическая реализация составила 12411,9 млн. руб. или 99,9% от стоимости отпущенной энергии (Приложение 6).

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

1.2 Проектирование информационной системы

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

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

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

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

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

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

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

Разработка итерациями отражает объективно существующий спиральный цикл создания информационной системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям информационной системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков информационной системы. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании информационных систем с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл информационной системы в соответствии с методологией RAD состоит из четырех фаз: анализа и планирования требований; проектирования; построения; внедрения.

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

На этапе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации. Результатом данного этапа должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап нередко происходит неконтролируемое искажение данных. Применение единой среды хранения данных о проекте позволяет этого избежать. В отличие от обычных подходов, при которых используются специфические средства, не предназначенные для построения реальных приложений, а прототипы выбрасываются после устранения неясностей в проекте информационной системы, в подходе RAD каждый прототип передается будущей системе. Таким образом, на следующую фазу передается более полная и полезная информация.

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

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

а)разрабатывается совершенно новая система;

б)было проведено обследование предприятия и существует модель его деятельности;

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

При разработке проекта информационной системы, мы использовали CASE-инструмент BPWin 4.0.

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

Особенности программы:

Поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область более комплексно.

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

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

Недорог, распространён, по нему много информации и компетентных специалистов.

Лёгок в освоении и применении, есть курсы на русском языке.

Позволяет облегчить сертификацию на соответствие стандартам качества ISO9000

Является стандартом де-факто, интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.

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

Интегрирован со средством имитационного моделирования Arena . Имитационное моделирование - создание компьютерной модели системы (физической, технологической, финансовой и т. п.) и проведение на ней экспериментов с целью наблюдения/предсказания.

Содержит собственный генератор отчётов.

Позволяет эффективно манипулировать моделями - сливать и расщеплять их.

Имеет широкий набор средств документирования моделей, проектов.

С помощью данной программы мы нами были смоделированы схемы, представленные на рисунках 1-3:

Рисунок 1 - Работа с поставщиками

Рисунок 2 - Работа с потребителями

Рисунок 3 - Деятельность ОАО «Кировэнергосбыт»

Таким образом, с помощью CASE-инструмент BPWin 4.0, нами были разработаны схемы взаимодействия поставщиков и организации, организации и потребителей и общая схема работы гарантирующего поставщика ОАО «Кировэнергосбыт».

1.3 Выбор средств разработки информационной системы

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

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

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД. Среди данных СУБД можно назвать: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Среди таких СУБД можно выделить: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Cachй, ЛИНТЕР.

Встраиваемая СУБД -- СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Paradox был разработан компанией Ansa Software, и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Borland. С июля 1996 года он принадлежит компании Corel и является составной частью Corel Office Professional.

В конце 80-х - начале 90-х годов Paradox, принадлежавший тогда компании Borland International, был весьма популярной СУБД, в том числе и в нашей стране, где он одно время занимал устойчивые позиции на рынке средств разработки настольных приложений с базами данных.

Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase - каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).

Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.

Отметим, однако, что отсутствие формата данных имеет и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью этого формата библиотеки, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах - все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.

По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE - Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).

Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.

Текущая версия данной СУБД - Paradox 9, поставляется в двух вариантах - Paradox 9 Standalone Edition и Paradox 9 Developer"s Edition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Corel Office Professional, второй - в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:

а)Средства манипуляции данными Paradox и dBase.

б)Средства создания форм, отчетов и приложений.

в)Средства визуального построения запросов.

г)Средства публикации данных и отчетов в Internet и создания Web-клиентов.

д)Corel Web-сервер.

е)ODBC-драйвер для доступа к данным формата Paradox из Windows-приложений.

ж)Средства для доступа к данным формата Paradox из Java-приложений.

Помимо этого Paradox 9 Developer"s Edition содержит:

Run-time-версию Paradox для поставки вместе с приложениями.

Средства создания дистрибутивов.

Драйверы SQL Links для доступа к данным серверных СУБД.

Язык программирования Delphi - язык программирования, который используется в одноимённой среде разработки и является комбинацией нескольких важнейших технологий:

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

Объектно-ориентированная модель компонент;

Визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;

Масштабируемые средства для построения баз данных. Сначала язык назывался Object Pascal. Начиная со среды разработки Delphi 7.0, в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal.

Все это делает данный язык оптимальным для написания на нем информационной системы.

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

История Delphi начинается с 60-х гг., когда профессор Н.Вирт разработал язык высокого уровня Pascal. Это был лучший язык для изучения программирования, и для создания программ для операционной системы MS-DOS. Затем, в 1983 г., А. Хейлсберг совместно с другими программистами, которые только что организовали компанию Borland, разработал компилятор Turbo Pascal, который стал следующим шагом в эволюции Delphi. Затем появился Object Pascal, который уже использовал Объектно-Ориентированный подход к программированию. Когда появилась первая версия Windows - Windows 3.10, Программисты Borland создали Delphi 1. Это уже была объектно-ориентированная среда для визуальной разработки программ, основанная на языке Object Pascal.

Основу Delphi составляет не только сам язык, но и RAD (Rapid Application Development) - среда быстрой разработки программ. Благодаря визуальному программированию, а также достаточно большой библиотеке визуальных компонентов, Delphi позволяет создавать программы наиболее быстро и эффективно, принимая на себя основную работу, и оставляя программисту творческий процесс. Разумеется, возможность быстрого создания профессиональных приложений для Windows делает Delphi - программистов востребованными во всех отраслях человеческой деятельности.

Изначально среда разработки была предназначена исключительно для разработки приложений Microsoft Windows, затем был реализован также для платформ GNU/Linux (как Kylix), однако после выпуска в 2002 году Kylix 3 его разработка была прекращена, и, вскоре после этого, было объявлено о поддержке Microsoft .NET. При этом высказывались предположения, что эти два факта взаимосвязаны.

Реализация среды разработки проектом Lazarus (Free Pascal, компиляция в режиме совместимости с Delphi) позволяет использовать его для создания приложений на Delphi для таких платформ, как GNU/Linux, Mac OS X и Windows CE.

Также предпринимались попытки использования языка в проектах GNU и написания компилятора для GCC.

1.3.3 Microsoft Access

Microsoft Office Access или просто Microsoft Access -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Основные компоненты MS Access:

Построитель таблиц;

Построитель экранных форм;

Построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

Построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

Microsoft Jet Database Engine, которая используется в качестве движка базы данных MS Access является файл-серверной СУБД и потому применима лишь к приложениям, работающим с небольшими объёмами данных и при небольшом числе пользователей, одновременно работающих с этим данными. Непосредственно в Access отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Встроенные средства взаимодействия MS Access со внешними СУБД с использованием интерфейса ODBC снимают ограничения, присущие Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют реализовать такое взаимодействие называются «связанные таблицы» (связь с таблицей СУБД) и «запросы к серверу» (запрос на диалекте SQL, который «понимает» СУБД).

Корпорация Microsoft для построения полноценных клиент-серверных приложений на базе MS Access рекомендует использовать в качестве движка базы данных СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

Известны также реализации клиент-серверных приложений на базе связки Access 2003 c другими СУБД, в частности, MySQL

Access, при работе с базой данных, иначе взаимодействует с жёстким (или гибким) диском, нежели другие программы.

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

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

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

1992 Access 1 для Windows 3.0

1993 Access 2.0 для Windows 3.1x (Office 4.3)

1995 Access 7 для Windows 95 (Office 95)

1997 Access 97 (Office 97)

1999 Access 2000 (Office 2000)

2001 Access 2002 (Office XP)

2003 Access 2003 (из комплекта программ Microsoft Office 2003)

2007 Microsoft Office Access 2007 (из комплекта программ Microsoft Office 2007)

2010 Microsoft Office Access 2010 (из комплекта программ Microsoft Office 2010)

2012 Microsoft Access 2013 (из офисного пакета приложений Microsoft Office 2013)

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

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

Механизмы масштабирования в СУБД Oracle последней версии позволяют безгранично увеличивать мощность и скорость работы сервера Oracle и своих приложений, просто добавляя новые и новые узлы кластера. Это не требует остановки работающих приложений, не требует переписывания старых приложений, разработанных для обычной одномашинной архитектуры. Кроме того, выход из строя отдельных узлов кластера также не приводит к остановке приложения.

Встраивание в СУБД Oracle JavaVM, полномасштабная поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA), привело к тому, что Oracle на сегодняшний день де-факто является стандартом СУБД для Internet.

Еще одной составляющей успеха СУБД Oracle является многоплатформенность, так как она поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе. Таким образом, компаниям, начинающим работу с продуктами Oracle не приходится менять уже сложившееся сетевое окружение. Существует лишь небольшое количество отличий при работе с СУБД, обусловленных особенностями той или иной операционной системы. В целом же это всегда та же самая безопасная, надежная и удобная СУБД Oracle.

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

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

СУБД Oracle поставляется в четырех вариантах Oracle Database Enterprise Edition, Oracle Database Standard Edition, Oracle Database Personal Edition и совсем облегченный мобильный вариант, предназначенный в первую очередь для laptop-ов. При этом все варианты сервера Oracle имеют в своем основании один и тот же код и функционально идентичны за исключением некоторых опций, которые например, могут быть доступны только для Oracle Database Enterprise Edition и не поставляться с другими вариантами СУБД.

Oracle Database Enterprise Edition - Полнофункциональная СУБД, возможности которой ограничены, пожалуй, лишь аппаратными ресурсами. По сути в Oracle Database Enterprise Edition включены все новейшие разработки по безопасному хранению, обработке и конечному представлению данных. Широкие возможности по масштабированию позволяют обеспечить работу сервера базы данных 24 часа в сутки, 7 дней в неделю, 365 дней в году, а развитые средства резервного копирования исключить возможность потери стратегически важной информации.

Oracle Database Standard Edition - СУБД, обладающая несколько ограниченными по сравнению с Oracle Database Enterprise Edition возможностями, что находит свое отражение в стоимости каждой из них. Может быть установлена на серверах поддерживающих не более четырех процессоров. Oracle Database Standard Edition является наилучшим решением для развертывания информационных систем в небольших организациях, рабочих группах или подразделениях больших предприятий.

...

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

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

курсовая работа , добавлен 11.10.2014


Понятия и виды CRM-системы, перспективы и развитие рынка программных продуктов различных производителей CRM. Функции, типы, сферы применения системы управления взаимоотношениями с клиентами. Разработка плана внедрения CRM-системы на примере ООО "ПК ИПМ".

дипломная работа , добавлен 13.12.2013


Разработка информационной системы в СУБД Microsoft Access на примере расчёта с клиентами в промтоварном магазине. Достоинства проектируемой программы. Создание отчетов, таблиц, установка связей между ними. Построение запросов в режиме Конструктора.

отчет по практике , добавлен 19.03.2015


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

дипломная работа , добавлен 05.07.2009


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

дипломная работа , добавлен 15.09.2012


Разработка информационной подсистемы "ЮГСтрой-Заказ" в СУБД 1С:Предприятие для автоматизации работы с клиентами. Уменьшение времени обработки запроса (времени работы с клиентом), защита базы данных, обеспечение простоты пользовательского интерфейса.

дипломная работа , добавлен 01.07.2011


Анализ принципа работы отдела продаж на примере "Радуга-ТВ". Математическое моделирование работы с клиентами отдела продаж. Выбор архитектуры информационной системы, средств ее проектирования. Выбор системы управления базой данных, программные требования.

дипломная работа , добавлен 20.07.2014


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

курсовая работа , добавлен 17.02.2013


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

дипломная работа , добавлен 02.10.2011


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

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

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

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

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

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

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

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .

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

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

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

Процесс разработки инвестиционного ПО

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

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

Процесс разработки встроенного ПО

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

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

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

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

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

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

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

Заключение

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

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

Направления работы Департамента персонала

1. Цели Департамента персонала

1.1. Привлечение и расстановка персонала.

1.2. Развитие и самореализация персонала.

1.3. Совершенствование системы мотивации персонала.

1.4. Реализация социальных программ.

1.5. Корректное оформление отношений с работниками и внешними

организациями

2. Задачи Департамента персонала :

2.1. Подбор персонала.

2.2. Адаптация персонала.

2.3. Разработка эффективной системы материальной и нематериальной

мотивации.

2.4. Мониторинг персонала

2.5. Обучение персонала.

2.6. Формирование резерва.

2.7. Развитие корпоративной культуры

2.8. Документационное обеспечение деятельности предприятия

Локальные нормативные документы;

Кадровое делопроизводство.

3. Система поиска и подбора персонала

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

3.1. Постоянный режим маркетинга рынка труда.

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

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

Параллельно отслеживаются источники поступления кандидатур и оценивается их эффективность.

3.2. Режим целевого поиска кандидатур на открытые вакансии.

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

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

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

4. Система адаптации персонала

Адаптация нового работника проходит по двум направлениям:

4.1. Адаптация нового сотрудника как специалиста .

Адаптация нового сотрудника происходит в течение испытательного срока, установленного от 1 до 3 месяцев (в зависимости от сложности работы). За этот период новый сотрудник должен:

Полностью освоить участок работы

Приобрести недостающие навыки и знания

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

Проявить уровень деловых качеств, соответствующих должности.

Управление адаптацией нового сотрудника:

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

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

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

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

4.2. Адаптация нового сотрудника как работника Компании.

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

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

5. Система материальной и нематериальной мотивации

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

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

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

5.3. Служба персонала разрабатывает систему нематериальной мотивации.

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

6. Мониторинг персонала

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

6.1. Контроль текучести персонала - проводится ежемесячно во всех филиалах Компании.

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

6.3. Контроль причин увольнения работников – проводится постоянно во всех филиалах сотрудниками отделов персонала.

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

7. Обучение персонала и формирование резерва

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

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

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

7.3. Формирование и развитие системы обучения персонала Компании.

Служба персонала вплотную занимается обучением персонала:

Составляет список ключевых позиций Компании,

Разрабатывает критерии деловой оценки персонала,

По результатам оценки составляет списки сотрудников, подлежащих

включению в резерв руководящих кадров,

Анализирует потребности в обучении,

Организует процесс обучения,

Разрабатывает системы критериев эффективности обучения,

Формирует базу данных по предлагаемым образовательным программам,

Руководит процессом внутреннего и внешнего обучения сотрудников.

8. Развитие корпоративной культуры

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

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

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

9. Документационное обеспечение деятельности Компании

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

Как, всё-таки, разработать реально работающую систему KPI в компании? Методик много, есть отдельные примеры, а вот найти алгоритм разработки реальной системы KPI, практически, невозможно. Надеюсь, читателю будет интересен предложенный алгоритм разработки системы KPI «с нуля» (когда еще ничего нет), заканчивая финальным результатом - работающей системой. Об этом в данной статье.

«Бог не на стороне больших батальонов, а на стороне лучших стрелков».

Вольтер

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

KPI - Key Performance Indicators - ключевые показатели эффективности деятельности подразделения, компании или предприятия. В русской аббревиатуре используется сокращение «КПЭ».

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

1. Где взять эти самые KPI, и какие они должны быть? Будут ли эти KPI достижимы, и как это определить?
2. Какие KPI важны, а какие нет?
3. Как с помощью KPI увязать ключевые сферы деятельности компании, да так, чтобы KPI для маркетинга не противоречили KPI для продаж?
4. Какую методологию реализации проекта использовать? Допустим, выбрали методологию Balanced Scorecard (BSC) - Сбалансированную систему показателей. Что нужно делать далее?
5. С чего начать такой проект, и чем он должен закончиться? И т.д.

Вопросов масса. Ответов, как обычно, в разы меньше.

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

Рассмотрим алгоритм создания системы KPI, когда стратегии развития бизнеса в компании нет. По шагам.

Шаг 1. Выбираем методологию реализации проекта создания системы KPI. Например, методологию Balanced Scorecard (BSC). Об этом я писал в статье «Как разработать «Штурвал руководителя»», но повторюсь. Это - классические 4 «стены». См. Рис.1. Суть коротко:

A. Финансы . Финансы в компании обеспечиваются, всё-таки, продажами товаров и услуг.

B. Продажи . Чтобы с продажами было всё нормально, нужны технологии/продукты - те, которые востребованы рынком и те, которые можно рынку предлагать (продавать).

C. Технологии/продукты . Чтобы с технологиями/продуктами было всё нормально, нужны специалисты - люди, которые их создают.

D. Люди . Чтобы люди (способные к этому) создавали конкурентоспособные продукты, им нужно платить, их нужно обучать и развивать и т.д. Тогда они будут создавать продукты, продукты будут продаваться, и у компании с финансами будет всё в порядке. Далее компания сможет снова и снова инвестировать в людей для создания новых технологий/продуктов. Технические специалисты (производственный персонал) реализуют проекты, за которые заказчики, собственно, и платят деньги.

Рис. 1. Очень упрощенно суть методологии Balanced Scorecard (BSC) - Сбалансированной системы показателей.

Шаг 2. Формируем структуру главных сфер деятельности компании. Например, для проектной компании - это:

«Стена» A

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

«Стена» B

2. Продажи .

3. Маркетинг .

«Стена» C

4. Ключевые направления развития (их состояние). Допустим, это - модернизация и расширение продуктовой линейки.

5. Пресейл .

«Стена» D

6. Производство (реализация проектов).

7. HR (управление персоналом).

Комментарий: стоит отметить, что многие компании добавляют к классическим 4-м «стенам» свои «стены» (5-ую, 6-ую), являющиеся важнейшими в деятельности компании. Например, логистический блок.

Шаг 3. Определяем те сферы, которые мы хотим усилить. Или сферы, по которым у нас есть явные «точки провалов». «Точки провалов» - это не полные провалы в бизнесе. Это - то, что не работает, или работает не очень хорошо. Задача понятна - ликвидировать «точки провалов». Такие «точки провалов» есть в каждой компании.

Пример задачи . Допустим, у нас, в целом, всё более-менее нормально, за исключением того, что Отраслевой Сегмент 1 перестал приносить прибыль, но мы видим, что перспективен Отраслевой сегмент 2 (или новая перспективная ниша), с которым нужно срочно начать работать.

Пример плана действий.

1. Подготовить/скорректировать продуктовую линейку для нового Отраслевого сегмента 2 (для краткости - новая отрасль - «НО»). Это - «стена» С.

2. Найти профессионального директора по продажам для «НО». Это - «стена» B и D, так как, это - задача для директора по продажам компании и для HR.

a. Разработать профиль клиента «НО». Это - «стена» B.

b. Разработать профиль директора «НО». Это - «стена» B.

c. Разработать основные параметры мотивации директора «НО». Это - «стена» B.

d. Разработать мотивационный лист директора «НО» и согласовать его. Это - «стена» D.

e. Осуществить поиск/хантинг директора «НО». Это - «стена» D.

3. Сформировать новый отраслевой департамент - для краткости - «НОД» - (бюджет, центры ответственности, штатное расписание и т.д.). Это - «стена» B.

a. Поставить задачи директору «НОД». Это - стена «B».

b. Разработать основные параметры мотивации продавцов «НОД». Это – «стена» B.

c. Разработать мотивационные листы продавцов «НОД» и согласовать их. Это - стена «D».

d. Осуществить поиск/хантинг продавцов в «НОД».

e. Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить. Это - «стена» B и D.

4. Поставить задачи пресейл для продвижения решений компании в «НО». Это - «стена» D.

5. Поставить задачи маркетингу для продвижения решений компании в «НО». Это - «стена» B.

Пример дерева целей и KPI.

«Стена» С

KPI (Технического директора):

• Подготовить/скорректировать продуктовую линейку для «НО».
• Поставить задачи пресейл для продвижения решений компании в «НО».

«Стена» B

KPI (Директора по продажам компании):

• Разработать профиль клиента «НО».
• Разработать профиль директора «НО».
• Разработать основные параметры мотивации директора «НО».
• Сформировать «НОД» (бюджет, центры ответственности, штатное расписание и т.д.).
• Поставить задачи директору «НОД» (после того, как HR найдёт директора).
• Поставить задачи маркетингу для продвижения решений компании в «НО».

KPI (Директора «НОД»):

• Разработать основные параметры мотивации продавцов «НОД». Согласовать их с директором по продажам компании и передать в HR.
• Отсмотреть продавцов (существующих и новых), принять решения.

«Стена» D

KPI (Директора по HR):

• Разработать мотивационный лист директора «НО» и согласовать его с Директором по продажам компании.
• Осуществить поиск/хантинг директора «НО» (найти профессионального директора по продажам).
• Разработать мотивационные листы продавцов «НОД» и согласовать их с директором «НОД».
• Осуществить поиск/хантинг продавцов в «НОД».
• Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить.

Комментарий: понятно, что есть задачи и для «стены» A - спланировать новые расходы в бюджете компании и т.д.

Итак, мы сформировали дерево целей и поставили цели и задачи, которые обеспечат создание нового отраслевого департамента (НОД).

1. Департамент должен будет возглавить профессиональный в этой отрасли директор по продажам.

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

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

Уважаемый читатель, наверняка, подумает: «Легко сказать: взять на работу профессионального директора по продажам нового отраслевого сегмента!». Сложно! Как делал автор? Я формировал несколько списков для HR.

1. Cписок №1. Крупные и средние компании, в которых есть смысл искать директора или заместителя директора аналогичного направления. Не получается, тогда:

2. Список №2. Меньшие по размеру компании, в которых есть смысл искать директора. Человек будет немного на вырост, но он будет внутри более отстроенной компании. И для него это будет карьерный рост. Не получается, тогда:

3. Список №1. Искать в крупных и средних компаниях сильного продавца, а не менеджера. Также на вырост. Не получается, тогда:

4. Список №1. Искать близкого по отраслевому признаку директора, с учетом его способностей освоить новую отрасль.

5. И т.д. Были и другие варианты.

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

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

Луций Анней Сенека Младший

Детали KPI можно формировать, используя, например, широко известную методологию постановки целей S.M.A.R.T. Поэтому,

Шаг 4. Изучить методологию целеполагания, которая будет использоваться при постановке целей.

Например, методологию постановки целей S.M.A.R.T.

Идём дальше. Определили сферы, которые мы хотим усилить. Или сферы, по которым у нас точно есть «точки провалов». Что дальше? Далее мы разрабатываем план действий (см. пример выше), который позволит нам усилить эти сферы и/или ликвидировать «точки провалов». Без целостного плана действий, построить систему KPI, которая объединит работу различных служб компании, не реально. Во всяком случае, довольно сложно.

Шаг 5. Разработка плана действий.

На Шаге 3 я показал пример плана действий, не самого тривиального, но который вполне можно реализовать, и такие планы действий довольно часто компаниями реализуются. Что важно? - содержательный подход к решению задач!

Шаг 6. Проверка плана действий на выполнимость.

Опыт показывает, что чаще всего, сразу понятно, какие пункты плана точно выполнимы. Главное - нужно внимательно посмотреть на те пункты, которые явно вызывают сомнения. И либо, немного подумать (например, устроить «мозговой штурм»), либо привлечь экспертов, либо, возможно, пойти другим, более простым, путём. Но, не следует ставить явно невыполнимые (недостижимые) цели и задачи!

Шаг 7. Построение дерева целей (и задач).

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

Шаг 8. Формирование перечня KPI с назначением ответственных сотрудников за конкретные KPI.

Пример дерева целей и формирования перечня KPI на основе плана действий приведен в примере выше.

Шаг 9. Формирование мотивационных листов.

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

«Невозможно решить проблему на том же уровне, на котором она возникла.

Нужно стать выше этой проблемы, поднявшись на следующий уровень».

Альберт Эйнштейн

Как реализовать такой проект?

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

Мы часто забываем, что человек - не машина. Поэтому на основании собственного опыта я бы рекомендовал следующее:

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

Далеко не всегда эффективно запускать крупный и сложный проект.

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

2. Небольшие пилотные проекты лучше делать в простейших и понятных средствах (например, в Word или в Excel). Для начала. Главное, это - содержательна часть таких проектов, «положенная на бумагу». При реализации совсем небольшой задачи сделанные ошибки (а они будут!) можно быстро исправить.

3. Провести полный цикл моделирования - от решения какой-то небольшой задачи, до формирования KPI с условным «назначением» ответственных и формированием условных мотивационных листов.

Пример. Допустим, в компании нет мотивационных листов (пока), нет системы KPI (пока), и ранее компания этот проект не реализовывала. Как смоделировать ситуацию? Выполнить пп.1-3. KPI не назначать (!), и мотивационные листы «не вручать» (!). Просто поручить ответственному менеджеру то, что для него прописано. А потом сравнить то, что было спланировано, и что реально получилось.

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

1. Обязательно формировать конечные цели проекта по созданию системы KPI. Цель - «выставить KPI» - «понятна». Но это всё равно, что «повысить эффективность бизнеса», «обеспечить дальнейший рост компании» и т.д.

Приведу пример спектра практических целей создания системы KPI:

a. Цель 1.1: проверка компетенций менеджеров и ключевых сотрудников с целью выявления «точек провалов» (некомпетентных сотрудников) и перспективных сотрудников (способных расти). Всё-таки, ключевые показатели эффективности должны показывать (и показывают!) эффективность и неэффективность.

b. Цель 1.2: проверка эффективности сфер бизнеса компании (продажи, производство, пресейл, маркетинг и т.д.) с этой же целью.

c. Цель 1.3: проверка эффективности бизнес-процессов и коммуникаций в компании. Большинство крупных целей и задач реализуется силами различных подразделений. От слаженности их работы зависит рост компании. Не больше и не меньше! Это и есть та самая эффективность, о которой мы часто говорим.

2. План действий обязательно проверять на выполнимость. Чтобы в нём не было недостижимых целей (и задач).

3. Обязательно назначать ответственных за конкретные KPI. Хотя бы моделировать это (для начала). Чтобы не получалось так, что за конкретные KPI реально никто не отвечает.

«То, что является делом всех, не является ничьим делом » .

Изаак Уолтон

4. Проект по созданию системы KPI обязательно заканчивать мотивационными листами. Чтобы сформированные KPI не оказались «вне закона». Если это - пилотный проект, пусть это будет несколько KPI на период 2-3-4 месяца. Это - тоже правильно.

Практический пример на основе методологии Balanced Scorecard (BSC).

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

Итак, очень условный план - только для примера.

1. KPI-1. Повысить маржинальность проектов не менее, чем на 7% за период времени не более, чем 6 месяцев.

Допустим, ключевые причины недостаточной маржинальности проектов следующие (условно):

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

Отсюда «вырастают» KPI следующего уровня для ряда служб компании. А именно (снова - условно):

2. KPI-1-1 (для Технической дирекции и руководителей проектов (РП)): выполнение проектов в сроки и в рамках бюджета проекта. Выполнен KPI по проекту - РП получил бонус. Нет - нужно разбираться, почему, а, возможно, и менять РП.

3. KPI-1-2 (для Блока маркетинга): вычислить отрасли, сегменты и ниши, более платежеспособные, чем те, с которыми сегодня работает компания. Подготовить презентацию и обосновать свои предложения. В течение <такого-то срока>.

4. KPI-1-3 (для Блока продаж): сформировать портфель проектов объемом не менее <такого-то>, в течение не менее <такого-то срока> (в плотном взаимодействии с маркетингом, чтобы не терять время). Чтобы была возможность выбора проектов для реализации.

5. KPI-1-4 (для Блока закупок) пока нет. Первоначально можно поставить задачу – проработать и дать предложения, как уменьшить стоимость закупаемого оборудования под проекты.

Дипломная работа

Разработка информационной системы поддержки пользователей на базе 1С: Предприятие

Аннотация

В данном дипломном проекте разработана информационная система поддержки пользователей на базе 1С: Предприятие.

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

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

Ил. 31. Табл. 4. Библ.. 12.

Введение........................................................................................................................

Системотехническая часть

1 Характеристика объекта информатизации

2 Назначение и задачи взаимодействия подразделений системы

3 Постановка задачи на проектирование

4 Обзор существующих систем

5 Обзор и анализ материалов

6 Разработка проекта ИС

6.1 Описание основных функций системы

6.2 Описание существующего процесса

Специальная часть

1 Разработка структуры базы данных системы

2 Разработка ИС

3 Внедрение и тестирование ИС

3.1 Внедрение ИС

3.2 Тестирование ИС

4 Программные руководства

4.1 Руководство администратора

4.2 Руководство оператора

Организационно-экономическая часть

1 Расчет затрат на создание ИС

2 Оценка эффективности проекта

Охрана труда и безопасность жизнедеятельности

1 Перечень возможных профессиональных вредностей и опасностей

2 Меры и устройства, защищающие от указанных вредностей и опасностей

2.1 Меры защиты от излучений

2.2 Меры защиты от излучений

2.3 Меры защиты от шума

2.4 Требования к качеству воздушной среды и микроклимату

2.5 Меры обеспечения освещённости

2.6 Меры по нормализации эргономических факторов

2.7 Организация режима труда и отдыха

Заключение

Список использованных источников

Перечень листов графического материала

Приложение А. Печатные отчёты разработанной системы

Введение

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

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

1) Внедрение возможности пользователям самостоятельно делать заявки о неисправностях без звонка в отдел поддержки;

2) Обеспечение удобства работы с системой, как пользователей ПК, так и инженеров отдела поддержки пользователей;

) Обеспечение прозрачности системы, пользователь должен видеть, в каком состоянии находится его заявка;

) Обеспечение своевременного выполнения заявок пользователей инженерами отдела поддержки;

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

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

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

предметная область модель информационная система

1. Системотехническая часть

1.1 Характеристика объекта информатизации

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

1.2 Назначение, задачи и взаимодействия подразделений системы

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

1) Создание заявки пользователем.

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

) Рассмотрение заявки.

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

) Уточнение заявки.

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

) Выполнение и закрытие заявки.

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

) Удаление заявки.

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

Общий вид взаимодействия отдела поддержки с пользователями и внутри себя представлен на рисунке 1.1.

Рисунок 1.1 - Взаимодействие отдела поддержки с пользователями.

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

1) Пользователи - колл-центр:

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

Пользователям передается информация о выполнении заявок отделом поддержки.

) Колл-центр - отдел удаленной поддержки:

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

) Колл-центр - отдел поддержки на местах:

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

Колл-центру передается информация о выполненных заявках.

4) Отдел удаленной поддержки - отдел поддержки на местах:

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

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

) Отдел поддержки на местах - технический отдел:

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

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

) Отдел поддержки на местах - отдел материального обеспечения:

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

Отделу поддержки на местах передается информация по заявкам и комплектующие, картриджи и т.п. по этим заявкам.

) Отдел удаленной поддержки - пользователи:

Пользователям передается информация по заявкам и оказывается помощь в решении их проблем (например, настроить домашнюю страницу в браузере на <#"600287.files/image002.jpg">

Рисунок 1.2 - Базовые компоненты OMNITRACKER

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

) OMNITRACKER Email Gateway

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

) OMNITRACKER Web Gateway

Обеспечивает прямой доступ к базе данных OMNITRACKER через обычные веб-браузеры.

) OMNITRACKER CTI Gateway

Включает в себя системы телекоммуникации (телефония) на базе ПК с поддержкой TAPI. CTI: Computer Telephony Integration - Интеграция с компьютерной телефонией

) OMNITRACKER Interface Gateway

Содержит функции для интеграции сторонних систем kak, naprimer, SAP, систем управления сетью и многих других.

) OMNITRACKER Scanning Gateway

Инвентаризует компоненты IТ-сети с поддержкой WMI и автоматически сохраняет результаты в базе данных OMNITRACKER.

) OMNITRACKER Mobile Gateway

Решение для автономной обработки данных в мобильных системах (PDA) и их синхронизации с центральной базой данных OMNITRACKER.

) OMNITRACKER GIS Gateway

Предлагает интуитивно управляемый и многофункциональный планировщик маршрутов, например, для оперативного управления внешним персоналом и специалистами по техническому обслуживанию. Составной частью OMNITRACKER GIS Gateways является доступ к Геоинформационной системе („GIS“) со встроенными географическими картами

) OMNITRACKER Dashboard

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

Другие преимущества OMNITRACKER:

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

) Способность к интеграции

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

Базы данных (через интерфейсы ODBC)

Импорт данных из служб каталога (LDAP, ADSI, NDS)

Кроме того, благодаря встроенному программируемому COM-интерфейсу автоматизации, OMNITRACKER очень легко интегрируется практически во все предлагаемые на рынке системы, например, в пакет Microsoft Backoffice.

) Анализ и статистика

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

Пример работающего комплекса OMNITRACKER:

Рисунок 1.3 - Пример работающего комплекса OMNITRACKER

Рисунок 1.4 - Пример работающего комплекса OMNITRACKER

1.5 Обзор и анализ материалов

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

Литература по программированию;

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

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

Общие требования к функциональности ИС на предприятии;

Обеспечение информационной безопасности ИС;

Разграничение зон ответственности.

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

) Литература по программированию.

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

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

Данная документация необходима для:

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

Разрешения вопросов, связанного с настройкой ПО.

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

1.6 Разработка проекта информационной системы

1.6.1 Описание основных функций системы

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

1) Колл-центр;

2) Отдел удаленной поддержки;

) Отдел поддержки на местах;

) Технический отдел;

) Отдел материального обеспечения.

Колл-центр реализует следующие функции:

Прием звонков от пользователей;

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

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

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

Отдел удаленной поддержки реализует следующие функции:

Помощь пользователям (например, подсказать почему не отправляется почта с прикрепленным файлом на 2Гб).

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

Отдел поддержки на местах реализует следующие функции:

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

Замена комплектующих или картриджей на местах.

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

Ремонт поврежденной техники (например, перепаять конденсаторы на материнской плате);

Сборка и настройка новой техники (например, собрать ПК, установить ОС и настроить её, перепрошить принтер для работы с неоригинальными картриджами);

Заправка картриджей.

Отдел материального обеспечения реализует следующие функции:

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

Выдача новой техники.

Списание старой техники.диаграмма вариантов использования системы с её главными функциями представлена на рисунке 1.5.

Рисунок 1.5 - UML-диаграмма вариантов использования

1.6.2 Описание существующего процесса

Процесс поддержки пользователей включает в себя несколько этапов:

1) Пользователь создает заявку или звонит в колл-центр;

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

) При передаче заявки отделу удаленной поддержке он выполняет заявку и передает её на закрытие в колл-центр, при невозможности выполнения передает заявку в отдел поддержки на местах;

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

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

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

) После выполнения заявки она возвращается в колл-центр, который передает информацию о заявке пользователю и закрывает её.

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

Рисунок 1.6 - UML-диаграмма деятельности

2. Специальная часть

2.1 Разработка структуры базы данных системы

Основными единицами структуры системы 1С: Предприятия являются справочники и документы.

Справочник - это агрегатный тип данных, средство для работы со списками однородных элементов данных. Название и структура каждого конкретного справочника определяются при его создании в конфигураторе. У любого справочника существуют два реквизита, которые создаются автоматически - «Код» и «Наименование». Реквизиты справочников могут быть периодическими, т.е. иметь значения, связанные с датой. При изменении значения периодического реквизита старое значение сохраняется, при этом новое значение начинает действовать с указанной даты, старое - до указанной даты. В разрабатываемой системе имеется 7 справочников: «Пользователи», «Инженеры», «Отделы», «ТипТехники», «Техника», «ТипСостояния» и «Заявки».

Рассмотрим более подробно каждый из справочников.

1) Справочник «Пользователи» предназначен для хранения информации о пользователях и состоит из следующих полей (Рисунок 2.1):

ФИО (тип - строка);

Местонахождение (тип - строка);

Телефон (тип - строка).

Рисунок 2.1 - Форма справочника «Пользователи»

2) Справочник «Инженеры» предназначен для хранения информации о инженерах поддержки (Рисунок 2.2). Он состоит из полей:

ФИО (тип - строка);

Должность (тип - строка);

Отдел (тип - Справочник.Отделы).

Рисунок 2.2 - Форма справочника «Инженеры»

2) Справочник «Отделы» предназначен для хранения информации о отделах и содержит следующие поля (Рисунок 2.3):

Отдел (тип - строка);

Расшифровка (тип - строка).

Рисунок 2.3 - Форма справочника «Отделы»

3) Справочник «ТипТехники» предназначен для хранения информации о типах обслуживаемой компьютерной техники (Рисунок 2.4). Он включает в себя следующие поля:

Название (тип - строка);

Описание (тип - строка).

Рисунок 2.4 - Форма справочника «ТипТехники»

4) Справочник «Техника» предназначен для хранения информации об обслуживаемой компьютерной технике и содержит следующие поля (Рисунок 2.5):

Название (тип - строка);

Тип техники (тип - Справочник.ТипТехники);

Пользователь (тип - Справочник.Пользователи).

Рисунок 2.5 - Форма Справочник «Техника»

Справочник «ТипСостояния» предназначен для хранения информации о возможных типах состояния заявок (в работе, выполнена и т.п.) (Рисунок 2.6). Содержит следующие поля:

Название (тип - строка);

Описание (тип - строка).

Рисунок 2.6 - Форма справочника «ТипСостояния»

5) Справочник «Заявки» является основным справочником и предназначен для хранения информации о заявках пользователей в отдел поддержки (Рисунок 2.7). Он содержит в себе следующие поля:

Описание проблемы (тип - строка);

Состояние (тип - Справочник.ТипСостояния);

Создато (тип - дата);

Закрыто (тип - дата);

Пользователь (тип - Справочник.Пользователи);

Техника (тип - Справочник.Техника);

Инженер (тип - Справочник.Инженеры);

Решение (тип - строка).

Рисунок 2.7 - Форма справочника «Покупатели»

Документы в системе 1С: Предприятие используются для ввода, просмотра и корректировки информации о совершаемых хозяйственных операциях. У любого документа есть три обязательных реквизита «ДатаДок», «ВремяДок», «НомерДок». Дата и время, - наиболее важные характеристики документов, так как позволяют устанавливать строгую временную последовательность совершения операций.

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

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

Рассмотрим структуру каждого из них.

1) Документ «Регистрация пользователя» предназначен для регистрации нового пользователя в системе (Рисунок 2.8). Он содержит следующие реквизиты:

ФИО (тип - строка);

Местонахождение (тип - строка);

Телефон (тип - строка).

Рисунок 2.8 - Документ «Регистрация пользователя»

Документ «Регистрация инженера» предназначен для регистрации нового инженера поддержки в системе (Рисунок 2.9). Он содержит следующие реквизиты:

ФИО (тип - строка);

Должность (тип - число);

Отдел (тип - Справочник.Отделы).

Рисунок 2.9 - Документ «Регистрация инженера»

2) Документ «Регистрация техники» предназначен для регистрации новой компьютерной техники в системе (Рисунок 2.10). Он содержит следующие реквизиты:

Название (тип - строка);

Тип техники (тип - Справочник.ТипТехники);

Пользователь (тип - Справочник.Пользователи).

Рисунок 2.10 - Документ «Регистрация техники»

Документ «Заявка создание» для создания новых заявок от пользователей. (Рисунок 2.11). Документ состоит из следующих реквизитов:

Описание проблемы (тип - строка);

Пользователь (тип - Справочник.Пользователи);

Техника (тип - Справочник.Техника);

Инженер (тип - Справочник.Инженеры).

Рисунок 2.11 - Документ «Заявка создание»

3) Документ «Заявка закрытие» предназначен для закрытия завяки после того, как она была выполнена. (Рисунок 2.12). Документ состоит из следующих реквизитов:

Заявка (тип - Справочник. Заявки);

Рисунок 2.12 - Документ «Заявка закрытие»

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

В данной системе имеется 3 основных отчётов (Приложение А):

1) «Инженеры» - выводит данные по количеству выполненных заявок по справочнику заявки за выбранный период для выбранного инженера. Имеет печатную форму;

2) «Пользователи» - выводит данные по количеству созданных заявок по справочнику заявки за выбранный период для выбранного пользователя. Имеет печатную форму;

) «Техника» - выводит данные по количеству созданных заявок по справочнику заявки за выбранный период для выбранной техники. Имеет печатную форму.

2.2 Разработка информационной системы

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

Рассмотрим подробно структуру отчета «Инженеры». При создании формы отчета, в модуле формы автоматически формируется процедура ПриОткрытии(), предназначенная для открытия.

Процедура ПриОткрытии ()

//автоматически выбирает временной интервал отчета при открытии

Конец=РабочаяДата();

Начало=НачМесяца(Конец);

КонецПроцедуры

Отчет имеет печатную форму. Печатная форма полностью формируется средствами встроенного языка 1С, что придает большую гибкость программе. Для данного случая она осуществляется следующим образом (Приложение А):

Процедура Сформировать()

Заявки=СоздатьОбъект("Справочник.Заявки");

Заявки.ВыбратьЭлементы();

Таб=СоздатьОбъект("Таблица");

Таб.ИсходнаяТаблица("Сформировать");

Таб.ВывестиСекцию("Шапка");

кво=0; //переменная считает количество выведенных элементов

Пока Заявки.ПолучитьЭлемент()=1 Цикл

// пока есть очередной получаемый элемент

ТЭ=Заявки.ТекущийЭлемент();

// временная переменная для краткости

Если ТЭ.Инженер=ТекущийИнженер Тогда

// поиск выбранного инженера

Если ТЭ.Создано>=Начало Тогда

// поиск поиск по дате создания заявки

Если ТЭ.Закрыто<=Конец Тогда

// поиск поиск по дате закрытия заявки

Наименование=ТЭ.Наименование;

Пользователь=ТЭ.Пользователь;

Техника=ТЭ.Техника;

Решение=ТЭ.Решение;

ССостояние=ТЭ.Состояние;

Таб.ВывестиСекцию("Элемент");

кво=кво+1;

КонецЕсли;

КонецЕсли;

КонецЕсли;

КонецЦикла;

Таб.ВывестиСекцию("Подвал");

Таб.ТолькоПросмотр(1);

Таб.Показать("Сформировать","");

КонецПроцедуры

Все остальные документы и отчёты формируются по такому же принципу.

Проведение документов рассмотрим на примере документа «Заявка создание»:

Процедура ОбработкаПроведения()

СправочникЗаявки = СоздатьОбъект("Справочник.Заявки");

СправочникЗаявки.Новый();

СправочникЗаявки.Наименование = Описание;

СправочникЗаявки.Техника = Техника;

СправочникЗаявки.Пользователь = Пользователь;

СправочникЗаявки.Инженер = Инженер;

СправочникЗаявки.Решение = "Передано исполнителю";

СправочникЗаявки.Создано = ДатаДок;

СправочникЗаявки.Записать();

КонецПроцедуры

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

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

Для разрабатываемой информационной системы необходим следующий список пользователей (Рисунок 2.13):

Администратор (обладает полным правом доступа ко всей системе);

Инженер колл-центра (может редактировать документы и справочники кроме служебных (ТипТехники, ТипСостояния, Отделы);

Инженер (может редактировать и создавать заявки).

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

2.3 Внедрение и тестирование ИС

2.3.1 Внедрение ИС

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

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

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

2.3.2 Тестирование ИС

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

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

Результаты проведения тестирования программного продукта приведены ниже на рисунках 2.14 - 2.19.

Рисунок 2.15 - Реализация доступа к справочнику «Заявки»

Рисунок 2.16 - Реализация печатной формы справочника «Заявки»

Рисунок 2.17 - Реализация формы создания элемента справочника «Заявки»

Рисунок 2.18 - Реализация формы отчета «Инженеры».

Рисунок 2.19 - Результат работы отчета «Инженеры».

Отчёты «Пользователи», «Техника» приведены в Приложении А.

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

2.4 Программные руководства

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

2.4.1 Руководство администратора

Разработанный программный продукт работает под управлением ОС Windows 2000\XP\Vista\7. Для работы с БД необходимо чтобы на компьютере было установлено 1С.Пердприятие 7.7. Программный продукт состоит из набора исполняемых файлов, хранящихся в папке «Поддержка пользователей». Для инициализации необходимо выполнить ряд действий:

Запустить 1С.Предприятие;

Добавить информационную базу, хранящуюся в папке «Поддержка пользователей» (Рисунок 2.20);

Рисунок 2.20 - Добавление информационной базы

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

2.4.2 Руководство оператора

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

Рисунок 2.21 - Набор функций и панель инструментов

3. Организационно-экономическая часть

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

1) Трудоемкость разработки программного продукта;

2) Заработную плату исполнителей;

) Себестоимость программного продукта;

) Экономический эффект;

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

3.1 Расчёт затрат на создание ИС

Для определения трудоемкости работ, необходимо выделить этапы всех основных видов работ и распределить их по исполнителям.

Перечень основных операций, выполняемых разработчиком ИС:

Исследование предметной области и поиск соответствующей литературы;

Постановка задачи, формулирование требований к разрабатываемой системе;

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

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

Отладка и тестирование системы;

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

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

Общая трудоемкость разработки ИС определяется по следующей формуле:

ТР=S8·ti·Ri·КВН·S, чел/ч,(1)

где 8 - средняя продолжительность рабочего дня при 40-часовой рабочей недели в часах;- продолжительность выполнения i-ой работы в днях;- общее число исполнителей, выполняющих i-ую работу;

КВН - коэффициент выполнения норм;- количество рабочих смен.

Таблица 3.1 - Данные о выполняемых работах, их продолжительности и исполнителях, а также данные о трудоёмкости выполнения работ

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

Примем КВН=1, так как планируется стопроцентное выполнение норм. Так как инженеры - программисты обычно работают в одну смену, возьмем S=1.

Учитывая принятые показатели, формула (1) примет вид:

ТР=å8·ti·Ri, чел/ч (2)

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

Таким образом, общая трудоемкость разработки информационной системы составила 288 чел/ч.

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

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

Ведущий инженер-программист - 25000 руб/мес;

Инженер-программист 1 категории - 15000 руб/мес.

Дневная ставка исполнителя (Сдн) рассчитывается делением месячного оклада (ОМ) на среднее количество рабочих дней в месяце:

Сдн=Ом/22, (руб/день)(3)

Отсюда дневная ставка ведущего инженера-программиста составляет 1136 рублей в день, а инженера-программиста 1-й категории - 682 рублей в день.

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

Зi=åk×Сдн×tрi,руб,(4)

где k - количество исполнителей;

Сдн - дневная ставка исполнителя (рубли в день);

tрi - продолжительность i-ой работы.

Таблица 3.2 - Заработная плата исполнителей

Квалификация исполнителя	Кол-во исполнителей	Дневная ставка, руб/день	Часовая ставка, руб./час	Продолжительность работы, дни	Заработная плата исполнителей, руб.
Ведущий инженер-программист
Инженер-программист 1-ой категории

Таким образом, общие затраты на заработную плату всех исполнителей составили 34318 рублей.

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

Для определения себестоимости системы составим калькуляцию себестоимости и сведем в таблицу 3.3.

Таблица 3.3 - Калькуляция себестоимости системы

Статьи затрат	Сумма, руб.	Примечание
1. Основная заработная плата исполнителей		Итого таблицы 3.1 и таблицы 3.2
3. Отчисления на социальное страхование		30,2% от (п.1+п.2)
4. Затраты на электроэнергию		См. примечание 3.1
5. Стоимость услуг Интернет - провайдера		См. примечание 3.2
6. Амортизация оборудования		См. примечание 3.3
7. Накладные расходы		50% от заработной платы (п.1 + п.2)

Примечание 3.1 Стоимость израсходованной электроэнергии вычисляется из следующих параметров:

Продолжительность работы средств разработки: 41 день со средней продолжительность рабочего дня 8 часов;

Стоимость 1 кВт/ч: 4 руб.

Потребляемой мощность: 500Вт.

Итого, 41∙8∙4∙0,5 =656 руб.

Примечание 3.2 Стоимость услуг Интернет-провайдера вычисляется из следующих параметров:

Абонентская плата 350 рублей в месяц.

Итого, 350*2=700 рублей.

Примечание 3.3 Амортизация оборудования вычисляется исходя из следующих параметров:

Стоимость средств разработки: 20000 рублей;

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

Агод=20000/4=5000

Для разработки системы необходимо 41 день работать на компьютере (см. таблицу 3.1).

По этому, Аразработки=(5000/365)*41=561,6

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

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

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

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

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

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

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

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

Таким образом, затраты на разработку и внедрение автоматизированного рабочего места оператора информационной системы составили 69942,7 рублей.

3.2 Оценка эффективности проекта

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

ЕЭ=ЗСТ - ЗН, (5)

где ЗСТ - затраты на решение задачи без использования специального программного продукта (в рублях);

ЗН - затраты на решение задачи с использованием разработанной ИС (в рублях).

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

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

Пусть работу выполняет 2 сотрудника с месячным окладом 15000 рублей. Время работы компьютерной техники за год (считаем, среднее количество рабочих дней в месяце, равное 22) - 2112 часов (годовой фонд времени работы оборудования при односменном режиме работы и 8-часовом рабочем дне). Исходя из этого, можно определить затраты на электроэнергию и амортизационные отчисления в год.

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

Таблица 3.4 - Затраты при работе без программного обеспечения и с использованием системы

Статьи затрат	С использованием системы	Без использования системы	Примечание
1. Основная заработная плата
2. Дополнительная заработная плата
3. Отчисление на социальное страхование			30,2% от (п.1+п.2)
4. Затраты на электроэнергию (при работе на компьютере)			См. примечание 3.5
5. Амортизационные отчисления			См. примечание 3.4
6. Накладные расходы

Примечание 3.4 Амортизационные отчисления вычисляются исходя из следующих параметров:

Стоимость средств разработки: 40000 рублей;

Срок использования до полного обновления: 4 года.

Таким образом, Агод=40000/4=10000,

Норма амортизации: На=10000/40000*100%=25%

Примечание 3.5 Стоимость израсходованной электроэнергии вычисляется из следующих параметров:

Продолжительность работы средств разработки: 2112 часов;

Стоимость 1 кВт/ч: 4 руб.

Потребляемой мощность: 500Вт (каждый ПК).

Итого, 2112∙4 = 8448 руб. Таким образом, экономия денежных средств при использовании разработанного программного продукта составляет:

ЕЭ =695592 - 250312 = 445280(рублей).

Срок окупаемости затрат (О, лет) вычисляется по формуле:

О= ЗР / ЕЭ0 (6)

Значения ЗР (затраты на разработку системы) и ЕЭ были вычислены выше. Подставим их в формулу и получим значение окупаемости затрат:

О=69942,7/ 445280 = 0,16 года.

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

4. Охрана труда и безопасность жизнедеятельности

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

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

Риск поражения повышенным значением напряжения в электрической сети (220 В);

Возможность возникновения пожара;

Электромагнитное излучение по магнитной составляющей от 4 до 70 мГаусс (ПДУ 4 мГаусс согласно инструкции СанПин 2.2.4/2.1.8.055-96), по электрической составляющей от 2,5 до 25 В/м (ПДУ 10В/м согласно инструкции СанПин № 2152-90 п.6.6);

Рентгеновское излучение 0,03-0,07 мкР/ч (ПДУ 0,05мкР/ч согласно инструкции СанПин 2.2.4/2.1.8.055-96);

Ультрафиолетовое излучение 7-15 Вт/кв.м (ПДУ 10 Вт/кв.м согласно инструкции СанПин 2.2.4/2.1.8.055-96);

Электростатическое поле 300-320 В/см (ПДУ 300В/см согласно инструкции СанПин 2.2.4/2.1.8.055-96);

Постоянный однотонный шум в помещении, где расположены принтеры и т.п. (ПДУ 50 дБ согласно инструкции СанПин 2.2.4/2.1.8.055-96).

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

Некомфортный микроклимат;

Недостаточная освещенность;

Не эргономичные предметы мебели и интерьера;

Монотонность труда;

Гиподинамия.

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

4.2 Меры и устройства, защищающие потребителя от вредностей и опасностей

4.2.1 Меры защиты от поражения электрическим током, возникновения пожара

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

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

Запрещается разбирать монитор и пытаться самостоятельно устранять неисправности (опасные для жизни высокие напряжения на элементах схемы монитора сохраняются длительное время после отключения электропитания);

Запрещается снимать крышку системного блока и производить любые операции внутри корпуса до полного отключения системного блока от электропитания;

Запрещается во время работы компьютера отключать и подключать разъемы соединительных кабелей;

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

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

4.2.2 Меры защиты от излучений

Для предотвращения вредного воздействия электромагнитного поля оператор также должен находиться на расстоянии не менее 0.5м от монитора с электронно-лучевой трубкой (ЭЛТ).

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

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

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

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

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

Для нейтрализации повышенного уровня пульсации светового потока при подборе вычислительной техники следует отдавать предпочтение мониторам с низкими уровнями излучений, отвечающим стандарту MPR 1990:8, MPR 1990:10, TCO 99, ТСО 01 и повышенными визуальными характеристиками, антибликовыми и антистатическими покрытиями. При работе монитора в течении продолжительного времени следует уменьшать яркость

При подборе монитора рекомендуется выбирать мониторы с высокими кадровыми развертками. При работе в графических режимах существует возможность менять частоту кадровой развертки от 60 до 120 Гц при различных режимах разрешения. В соответствии со стандартом TCO 95 оптимальными считаются частоты 75 и 85 Гц. Для графических работ рекомендуются разрешающие режимы 800x600, 1280x728, 1600x1200. Максимальных частот развертки можно добиться на разрешении 800x600. Также не следует пренебрегать более дорогими мониторами с антибликовым и антистатическим покрытием.

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

4.2.3 Меры защиты от шума

При выполнении работы на ЭВМ уровень шума не должен превышать 50 дБ. Шумящее оборудование (принтеры и т. п.), уровни шума которого превышают нормированные, должно находится вне помещения с ЭВМ. Снизить уровень шума в помещениях можно использованием материалов с максимальным коэффициентом звукопоглощения в области частот 63-8000 Гц для отделки помещения. Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, подвешенные в складку на расстоянии 15-20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

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

Применением бесшумных устройств (например, замена матричных принтеров струйными или лазерными). Работа с матричными принтерами при наличии прикрывающих крышек;

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

4.2.4 Требования к качеству воздушной среды и микроклимату

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

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

Необходимо заботиться о том, чтобы в воздухе отсутствовали различного рода загрязнения. Наиболее благоприятное значение температуры воздуха в помещении при работе с ЭВМ 19-21°С, относительная влажность воздуха 55-62%.

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

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

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

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

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

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

4.2.5 Меры обеспечения освещенности

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

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

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

Рабочие места должны располагаться от стен с оконными проемами на расстоянии не менее 1,5 м, от стен без оконных проемов на расстоянии не менее 1,0 м (Рисунок 4.3).

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

Рисунок 4.3 - Схема расположения ЭВМ относительно оконных проемов

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

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

4.2.6 Меры по нормализации эргономических факторов

Площадь на одно рабочее место должна составлять примерно 6,2м, а объем не менее 20,0 куб.м.

Конструкция рабочего стола должна обеспечивать оптимальное размещение на рабочей поверхности используемого оборудования с учетом его количества и конструктивных особенностей (дисплея, ПЭВМ, клавиатуры, копихолдера для документов и тл.), характера выполняемой работы, а также возможности выполнения трудовых операций в пределах досягаемости. Поверхность стола должна быть ровной, без углублений. Высота рабочей поверхности стола должна регулироваться в пределах 680-800мм; при отсутствии такой возможности высота рабочей поверхности составляет 725мм. Рабочий стол должен иметь пространство для ног высотой не менее 620мм, шириной - не менее 550мм, глубиной на уровне колен - менее 450мм и на уровне вытянутых ног - не менее 65Омм.

Конструкция рабочего стула (кресла) должна обеспечивать поддержание рациональной рабочей позы при работе, позволять изменять позу с целью снижения статического напряжения мышц шейноплечевой области и спины для предупреждения развития утомления. Рабочий стул (кресло) должен быть подъемно-новоротным и регулируемым по высоте и углам наклона сиденья и спинки, а также - расстоянию спинки от переднего края сиденья, при этом регулировка каждого параметра должна быть независимой, легко осуществляемой и иметь надежную фиксацию. Поверхность сиденья, спинки и других элементов стула (кресла) должна быть полумягкой, с неэлектризуемым и воздухопроницаемым покрытием, обеспечивающим легкую очистку от загрязнений. Ширина и глубина поверхности сиденья - не менее 400 мм; регулировка высоты поверхности в пределах 400-500 мм и углам наклона вперед до 150 и назад до 50; высота опорной поверхности спинки стула (кресла) 300+/-20 мм, ширина - не менее 380 мм; угол наклона спинки в вертикальной плоскости от 0 до 30 градусов (Рисунок 4.4).

Рисунок 4.4 - Схема рабочего места оператора ЭВМ

Подставка для ног должна иметь минимальную ширину опорной поверхности 400 мм; минимальную глубину опорной поверхности 300 мм, наклон опорной поверхности к горизонтали 10 или регулируемый 0-15. Край опорной поверхности должен быть регулируемым по высоте в пределах 40 - 150 мм от пола.

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

4.2.7 Организация режима труда и отдыха

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

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

Режимы труда и отдыха при работе с ПЭВМ зависят от категории трудовой деятельности. Все работы с ПЭВМ делятся на три категории:

Эпизодическое считывание и ввод информации в ПЭВМ или работа в режиме диалога (не более 2-х часов за 8-часовую рабочую смену).

Считывание информации с предварительным запросом не более 40 тыс. знаков или ввод информации не более - 30 тыс. знаков или творческая работа в режиме диалога не более 4-х часов за 8-часовую смену.

Считывание информации с предварительным запросом более 40 тыс. знаков или ввод информации более 30 тыс. знаков или творческая работа в режиме диалога более 4-х часов за 8-часовую смену.

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

Продолжительность непрерывной работы с ПЭВМ без регламентированного перерыва не должна превышать 2 часов.

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

При 8-часовой рабочей смене регламентированные перерывы целесообразно устанавливать:

Для 2 категории работ с ЭВМ через 2 часа от начала смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый пли продолжительностью 10 минут через каждый час работы;

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

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

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

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

Заключение

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

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

Разработанная система реализует следующие функции:

Ведение информационной базы;

Планирование работ;

Формирование различных видов отчетов.

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

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

Список использованных источников

1) Официальный сайт комплекса OMNITRACKER [Электронный ресурс]. - Режим доступа: #"600287.files/image030.jpg">

Рисунок 1 - Отчет по инженерам

Рисунок 2 - Отчет по пользователям

Рисунок 3 - Отчет по технике