Разработка требований к информационной системе предприятия экспресс-доставки

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

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

Введение

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

- структуризации информационных потоков,

- автоматизации отдельно взятых процессов,

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

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

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

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

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

Были поставлены следующие задачи для дипломной работы:

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

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

Проанализировать данные по компании экспресс-доставки.

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

Рассмотреть несколько программных продуктов.

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

Представить выводы по проведенной работе.

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

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

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

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

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

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

Глава 1.Теоретическая база процесса «Формирование требований»

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

1.1 Понятие информационной системы

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

К примеру, одним из наиболее известных трактований понятия ИС является определение от М.Р. Когаловского. Оно звучит следующим образом: "информационной системой называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей» [1, c.288].

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

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

Другое определение звучит так: «информационная система -- совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств»[3, Ст. 2]. Данное определение более тривиально и близко по своей сути к трактовке понятия ИС в узком смысле, которое определяет ИС как программно-техническую часть ИС в широком смысле, содержащую лишь системы управления базами данных (СУБД), непосредственно базы данных (БД) и другие используемые программные средства (Маглинец, 2008).

Можно выделить 4 направления информационных потоков (ИП), которые обычно обеспечиваются Информационной системой:

ИП из внешнего мира в систему

ИП из системы во внешний мир

ИП из системы в компанию

ИП из компании в систему

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

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

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

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

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

1.2 Формирование требований

Определив вкратце сущность Информационных систем, переходим непосредственно к тому, что нас интересует - к этапу Формирования требований. Независимо от того к какому стандарту или подходу, описывающему жизненный цикл ИС, мы обратимся, этап Формирования требований всегда является одним из первых в процессе создания ИС. Данный этап помогает Заказчику и Разработчику совместно ответить на вопросы:«Что именно нам требуется реализовать в рамках данного проекта автоматизации? Каковы истинные причины и цели этого проекта? Какие задачи должен решать продукт? Сколько времени и финансов потребуется на реализацию проекта автоматизации?». Как правило, на практике очень сложно соблюсти первоначальные рамки, обозначенные на предпроектной стадии. Связано это в основном с тем, что:«Первичные данные поступают из различных источников, характеризуются противоречивостью, неполнотой, нечеткостью, изменчивостью»[4]. Это еще одна причина, почему данная тематика (процесс Формирования требований) является актуальной - совершенствование подходов и выработка современных эффективных методик позволит повысить точность планирования, частично сократить издержки на автоматизацию, повысить качество продукта автоматизации на выходе. Также противоречивость первичных данных в некоторой степени объясняет необходимость документирования сформированных раннее требований. Как у Заказчика, так и у Разработчика при возникновении разногласий в степени реализации (или не реализации) тех или иных свойств или функций системы будет существовать источник, обращение к которому позволит разрешить данные разногласия.

Если рассматривать ИС в узком смысле, то здесь можно применить те характеристики качественных требований, которые предъявляются к Программному обеспечению (ПО). Насчитывается 10 таких общепризнанных характеристик:

Единичность - одно требование рассматривает одну единственную вещь.

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

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

Атомарность - невозможно разбить одно требование на несколько более мелких, не утратив при этом его завершенности.

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

Актуальность - требование не становится устаревшим про прошествию времени.

Выполнимость - возможность реализации требования в рамках проекта.

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

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

Проверяемость - возможность установить было ли реализовано требование при помощи осмотра, демонстрации, анализа или проведения теста. [6]

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

Требования [7]:

1. Условия или возможности, необходимые пользователю

для решения проблем или достижения целей;

2. Условия или возможности, которыми должна обладать

система или системные компоненты, чтобы выполнить

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

или другим формальным документам;

3. Документированное представление условий или

возможностей для пунктов 1 и 2.

“Требования - Это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы. Первичные данные поступают из различных источников, характеризуются противоречивостью, неполнотой, нечеткостью, изменчивостью. Требования нужны в частности для того, чтобы Разработчик мог определить и согласовать с Заказчиком временные и финансовые перспективы проекта автоматизации” [4].

В третьем пункте первого определения, приведенного из IEEE Standard Glossary of Software Engineering Terminology, говорится о документировании требований. Это значит, что настало время обратиться к выделению основных типов деятельности в процессе создания требований.

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

Сбор требований

Анализ требований

Документирование требований

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

1.2.1 Сбор требований

Первая стадия (Сбор требований) начинается с выявления Заинтересованных лиц.

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

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

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

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

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

Законодательные основы, оказывающие влияние на деятельность компании

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

Внутреннее устройство организации

Бизнес-процессы компании

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

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

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

1.2.2 Анализ требований

После того как требования были собраны, мы переходим к следующей стадии - к Анализу требований. На этом этапе необходимо выявить и устранить конфликты между требованиями и различными заинтересованными лицами, нормативными документами, законодательной базой, бизнес-процессами компании и действующими на предприятии системами. Устанавливаются общие границы проекта. Проводится классификация требований по уровням - 1)Бизнес-требования - описывают цель, задачи, назначение проекта создания ИС 2)Функциональные требования - предписывают требуемые варианты поведения ИС, определяющие способы рещения поставленных задач 3) Пользовательские требования - это задачи, решение которых является одной из первопричин создания конкретной ИС.

Несколько другой вариант классификации по ряду различных параметров приводится в главе Requirements Analysis по SWEBOK [9]:

Функциональные и нефункциональные требования

Внутренние (с другими требованиями) или внешние зависимости

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

Приоритет требований

Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения

Изменяемость/стабильность требований [9]

Другой популярной классификацией требований к программным системам по уровням является классификация FURPS+, разработал которую в 1992 году сотрудник компании Hewlett-Packard Роберт Грэйди. Её название представляет собой аббревиатуру по первым буквам слов Functionaliy, Usability, Reliability, Perfomance и Supportability. Под «+» обозначаются ограничения - Constrains.

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

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

Лицензирование - инструмент контроля над покупкой, установкой и использованием лицензий.

Почта - служба по обмену сообщениями.

Онлайн-помощь - возможность оказания помощи пользователям в режиме реального времени.

Печать - возможность вывода документов на печать.

Отчетность - инструменты по возможности создания отчетов.

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

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

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

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

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

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

Блок «+», Constrains, или Ограничения, все те требования, которые ограничивают разработчика в выборе средств. Могут касаться любого аспекта - реализации программного кода, используемых мощностей, форматам входных и выходных данных, ограничений на физические параметры, начиная с формы и размера аппаратного обеспечения и заканчивая необходимой температурной средой.

Проблема заинтересованных лиц.

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

Проблема инженеров

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

1.2.3 Документирование требований

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

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

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

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

Одним из источников, которыми регламентируется Документирование требований, является ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Также для использования в качестве основы для этого процесса могут использоватся стандарт IEEE Standard 830-1998, ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению».

1.3 Ключевые моменты

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

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

2. Требования направлены от Клиента, куда входит Руководство предприятия, конечные пользователи и другие Заинтересованные лица, к команде Разработчика - руководству проекта автоматизации, программистам, консультантам.

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

1.4 Основная проблема, связанная с требованиями

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

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

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

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

1)Недостаточность полученной от клиента информации

2)Неполнота требований

3)Внесение изменений в уже утвержденные требования

2. Глава 2. Формирование требований и выбор программного обеспечения для предприятия экспресс-доставки

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

2.1 Информация о Компании

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

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

Конфиденциальную корреспонденцию

Ценные бумаги

Валюту

Драгоценные металлы, камни, изделия и монеты

Ювелирные изделия

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

Опасные грузы и грузы специального назначения

Оружие и боеприпасы

Наркосодержащие средства

Психотропные вещества

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

Выделяя организационную структуру компании, следует сказать, что она состоит из Центрального аппарата, 7 региональных управлений, 63 территориальных управлений в регионах, в составе которых находятся 186 пунктов и отделений.

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



(рис.1 Организационная структура центрального аппарата Компании)

(рис.2 Организационная структура центрального аппарата Компании)



(рис.3 Организационная структура центрального управления по Москве и Московской области Компании)

2.2 Бизнес-процессы Компании

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

(рис.4 Основные бизнес-процессы Компании)

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

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

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

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

(рис. 4 Работа с клиентами, бизнес-процессы)

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

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

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

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

своевременная проверка и установка обновлений рабочего программного обеспечения

администрирование существующих баз данных

поддержание стабильной работы сайта Компании

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

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

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

Рассматривая типично отраслевую деятельность предприятия, можно особо обозначить несколько бизнес-процессов, а именно:

Прием отправлений в отделениях предприятия

Подготовка маршрута

Перевозка отправлений по внутриобластным и городским маршрутам

Вручение отправлений в помещениях получателя

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

2.3 Существующая Информационная Система

Проанализировав существующую информационную систему Компании, можно сказать, что ИС состоит из 3 уровней.

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

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

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

(Рис. 5 Уровни ИС предприятия)

2.4 Выявленные проблемы

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

2.4.1 Невозможность идентификации необходимых отправлений клиентом при их мониторинге

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

1) если это нестандартное отправление с более чем одним отправителем, сложным составным маршрутом (следовательно, оно не передается в корпоративную информационную систему)

2) если сбор осуществлялся в помещении отправителя (в этом случае номер присваивается позже, уже в отделении Компании)

3) если заявка обрабатывается вне КИС (как в 1 случае), то нет связи между заявкой на отправление и накладной (следовательно, снова нет приемочного номера)

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

2.4.2 Отсутствие возможности автоматизированной обработки некоторых заявок

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

2.4.3 Несвоевременное обеспечение клиентов информацией о получении/передаче отправления

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

2.4.4 Контроль отправлений

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

2.4.5 Обновление данных по маршрутам

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

2.4.6 Проблема со справочником маршрутов

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

2.4.7 Проблемы сортировки

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

2.4.8 Составление плана-задания на маршрут

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

2.4.9 Проблемы системы мониторинга

Программные и аппаратные средства Компании позволяют отслеживать перемещения только автомобильного транспорта. Более того, отслеживания транспорта по Москве и другим регионам России происходит не связанным между собой образом через различные сервера. Это препятствует получению отчетов и проведению анализа по всей текущей ситуации с транспортом, а не только по отдельному региону. Кроме этого на рабочих местах диспетчеров по Москве и другим регионам установлено различное программное обеспечение - ARCAN VISING 3.7 и ARCAN VISING 4.0.

информационный доставка мониторинг транспорт

2.4.10 Проблемы сервера для мониторинга транспорта по России

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

2.4.11 Проблема мониторинга сотрудников на маршрутах

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

2.4.12 Проблема контроля оружия

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

2.5 Заинтересованные лица

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

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

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

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

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

3.Компания разработчик/внедренец.

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

4. Клиенты компании.

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

5. Службы ИТ-поддержки предприятия.

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

6.Компании, отвечающие за смежные системы, взаимодействующие с

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

К примеру, система спутниковой навигации ГЛОНАСС/GPS при поддержке Федерального космического агентства (Роскосмос) и ОАО «Российская корпорация ракетно-космического приборостроения и информационных систем». Туда же относится Компания ООО «Бизнес логистика» (группа компаний «Аркан»), ответственная за сервера мониторинга транспорта и Услуги по приему, обработке, хранению и визуализации мониторинговой информации.

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

2.6 Цели и задачи проекта внедрения

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

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

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

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

обеспечение бухгалтерского и налогового учета деятельности всего предприятия,

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

систематизация и объединение необходимых данных всех отделений Компании

2.7 Требования

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

2.7.1 Направления для автоматизации

На предприятии существуют и нуждаются в автоматизации следующие направления:

Ведение бухгалтерского, управленческого и налогового учетов

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

Оформление, сбор, и анализ отчетности

Поддержка взаимоотношений с клиентами

Контроль персонала предприятия и управление им

Процесс расчета заработной платы работников

Контроль отправлений на складе

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

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

ПО должно обладать спосбностью гибкого дальнейшего конфигурирования и наращивания.

2.7.2 Функционально-отраслевые требования предприятия к ИС

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

Хранение и доступ к данным по существующим маршрутам

Построение маршрутов доставки отправлений

Хранение и доступ к информации по распределению населенных пунктов между управлениями и отделениями

Учет отправлений -рецистрация отправления, его времени получения, приёмного номер, адреса нахождения отправления, адреса назначения

Расчет времени доставки и выявление отклонений от сроков

Мониторинг статуса и приемного номера отправления

Отслеживание местоположения транспорта, отправления и сотрудника, выполняющего транспортировку

Регистрация и учет заявок от клиентов

Ведение договоров

Ведение клиентов

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

Выставление счетов на основании заявок

Поиск отправлений в системе

Получение информации о дате и времени приёма, виде отправления, его приёмном номере

Просмотр данных по клиенту

Отслеживание сроков действия договоров

Ввод, хранение, обработка и контроль данных по транспорту предприятия

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

Оптимизация и согласование маршрутов инкасации при помощи импорта Excel-таблиц от банков

Выставление счетов клиентам

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

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

Осуществление конфиденциального обмена данными между регионами и центром

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

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

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

Автоматизация обновления информации по маршрутам

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

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

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

2.8 Выбор ПО

При выборе программного обеспечения для автоматизации деятельности Компании мы рассмотрели несколько наиболее популярных программных продуктов. Среди них решения от Oracle, SAP, 1C, Microsoft. Помимо способности удовлетворить функциональные и бизнес-требования мы будем обращали внимание также на сроки и стоимость проектов внедрения, стоимость и доступность бслуживания, необходимость и сложность дополнительного обучения, если клиент не знаком с системой.

2.8.1 Microsoft Dynamics Ax (Axapta)

На базе Microsoft Dynamics Ax (Axapta) мы рассмотрели отраслевое решение для транспортных компаний от одного из интеграторов. Его значимость заключается в следующем - на базе этого продукта существует возможность автоматизировать бизнес-процессы, в чем существует потребность у рассматриваемого нами предприятия. Среди них учет отправлений морским, речным и автотранспортом, возможности:

Ведение бухгалтерского и налогового учета

...