Организация Интернет продаж
Создание интернет магазина

Проектирование автоматизированной системы ведения торгового учета

22.05.2015

Проектирование автоматизированной системы ведения торгового учета на предприятии оптово-розничной торговли на базе ERP-решений 1С

Цель работы – Спроектировать и разработать подсистему ведения торгового учета на торговом предприятии.
Основные задачи решаемые в работе: изучение и анализ стандартов, обзор и анализ рынка ERP систем в целом и в торговле в частности, построение комплекса моделей ARIS описывающих подсистему «Ведения торгового учета»,проведение технико-экономического обоснования работы.
В рамках теоретической части работы проведён анализ производственных стандартов, рассмотрена методология ARIS рассмотрены нотации использованных в практической части моделей, рассмотрена функциональность 1С: Предприятие с конфигурацией Управление торговлей, проанализирован рынок ERP систем в России.
Практическая часть содержит построенные модели в CASE-средстве ARIS для разработанной системы, техническое задание на разработку системы ведения торгового учета.
В рамках экономической части была проведена оценка технико-экономического эффекта от внедрения.
В заключении приводятся основные выводы и результаты, полученные в результате выполнения работы.

Список Сокращений:

MRP Material Resource Planning
MRP II Manufacturing Resource Planning планирование производственных ресурсов
ARIS Architecture of Integrated Information Systems
ГОСТ Государственный стандарт
CASE Computer-Aided Software Engineering
ERP (Enterprise Resource Planning System) Система планирования ресурсов предприятия
IDEF Integrated Computer-Aided Manufacturing
CRM Customer Relationship Management
SRM Supplier Relationship Management
ISO International Organization for Standardization
POS Point Of Sale - точка продажи
IEC/МЭК International Electrotechnical Commission -Международная электротехническая комиссия
НИР научно-исследовательская работа
ИС информационные технологии
НДС налог на добавленную стоймость
ПО программное обеспечение
АС автоматизированная система
ПС программное средство
ЖЦ жизненный цикл
СУБД система управления базами данных
SAP немецкая компания, крупнейший в Европе производитель программного обеспечения
ТЗ Техническое задание

Введение

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

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

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

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

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

Рынок ERP систем в мире и в России

Рост глобального рынка ERP – 6-8% в год - обеспечивается, в основном, за счет поглощения крупными вендорами более мелких разработчиков бизнес-приложений. Таким образом, наращивается общая клиентская база, увеличиваются доходы от сопровождения. Так или иначе, но в последние годы мировые ERP-вендоры значительно в большей степени озабочены поиском новых ниш для продажи своих решений и подходов к их продвижению. Любопытно, что значительная доля затрат пользователей приходится на поддержку уже внедренных ERP-систем. Примерное распределение доли рынка между основными производителями ERP-систем в 2008 году на мировом уровне представлено на рис.1

Доли рынка основных производителей ERP-систем в мире

Рисунок 1 Доли рынка основных производителей ERP-систем в мире

В России рынок ERP представлен на рис.2 [1]

Доли рынка основных производителей ERP-систем в России

Рисунок 2 Доли рынка основных производителей ERP-систем в России

Сегментация российского рынка ERP-систем по отраслям рис.3[24]

Сегментация российского рынка ERP-систем по отраслям

Рисунок 3 Сегментация российского рынка ERP-систем по отраслям

Преимущества ERP-систем

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

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

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

Недостатки ERP-систем

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

Ограничения ERP-систем заключаются в следующем:

Особенности ERP-решений в торговле

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

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

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

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

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

Не менее часто встречающейся задачей является интеграция ERP-системы со специализированными Retail-системами (например, TradeX), а также торговым оборудованием (POS-терминалами, сканерами штрих-кодов и т.п.), для чего необходимы соответствующие специалисты и программные решения, нигде, кроме торговли, не востребованные.

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

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

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

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

Методология ARIS

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

В семейство ARIS входят следующие модули:

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

В рамках каждого из перечисленных типов создаются модели разных видов, отражающие соответствующие стороны исследуемой системы. ARIS поддерживает большое количество методов моделирования, используемых для построения этих моделей. Среди них такие известные как диаграммы Чена, Unified Modeling Language (UML), Object Modeling Technique (OMT) и т.п. Последняя версия ARIS поддерживает более 83 методов моделирования.

Нотация ARIS Organizational Chart

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

Заложенные в нотацию типы связей позволяют отразить различные виды отношений между объектами организационной структуры. Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты можно использовать в дальнейшем при формировании моделей бизнес-процессов. При построении сложных иерархических структур может быть применена декомпозиция, например, структуру подразделения возможно представить более детально.[5] В таблице 1 представлены все основные связи и объекты в нотации Organizational Chart.

Таблица 1 Основные объекты, используемые при построении организационной диаграммы

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

Нотация ARIS еЕРС — расширение нотации IDEF3

Событийная цепочка процесса - (Extended event driven process chain - eEPC) описывает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются организационными единицами и позволяет осуществлять связь между организационной и функциональной моделями. Используется для описания сценария процесса и процедур. В табл.2 приводятся основные объекты, используемые в рамках нотации.

Таблица 2 Основные объекты, используемые при построении диаграмм еЕРС

Основные объекты, используемые при построении диаграмм еЕРС

Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). [23]

При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:

Бизнес-процесс в нотации ARIS еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загруженности персонала в процессе можно использовать другие инструменты описания, например диаграммы Гантта в системе MS Project. Схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS eEPS визуально представляется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в IDEF3.

Нотация ARIS Function Tree

Нотация ARIS Function Tree предназначена для формирования моделей дерева функций.

Дерево функций (Function Tree) – представляет иерархическое декомпозицию функций на подфункции:

Типы декомпозиций функций:

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

Таблица 3 Основные объекты и связи функционального представления процесса

Основные объекты и связи функционального представления процесса

Учет товародвижения

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

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

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

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

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

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

Момент продажи товаров обусловливает метод определения выручки от продажи: метод начисления («по отгрузке») или кассовый метод («по оплате»).

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

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

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

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

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

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

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

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

Обзор функциональности 1С Предприятие 8 с конфигурацией «Управление торговлей»

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

"1С:Управление торговлей 8" — это современный инструмент повышения эффективности бизнеса торгового предприятия.

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

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

Прикладное решение автоматизирует следующие направления хозяйственной деятельности:

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

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

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

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

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

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

Модель ЖЦ ИС включает в себя:

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

Каскадная модель

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

Рисунок 4 Классический жизненный цикл разработки ПО

Классический жизненный цикл разработки ПО

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

Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

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

Проектирование состоит в создании представлений:

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

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

Инкрементная модель

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

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

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.

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

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

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

Рисунок 5 Инкрементная модель

Инкрементная модель

Забегая вперед, отметим, что современная реализация инкрементного подхода — экстремальное программирование ХР (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

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

Спиральная модель

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

Рисунок 6 Спиральная модель

Спиральная модель

1 — начальный сбор требований и планирование проекта;
2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе
начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход
к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета;
8 — сконструированная система; 9 — оценивание заказчиком.

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

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

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

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

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

Достоинства спиральной модели:

Недостатки спиральной модели:

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

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

Стандарты

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

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

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

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

ГОСТ 34.601-90 – распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

ГОСТ 34.601-90

ГОСТ 34.601-90 распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях.
Данный стандарт устанавливает следующие стадии создания АС:

В рамках каждой стадии создания АС выполняется определённый набор работ:
1. Формирование требований к АС:
1.1. Обследование объекта и обоснование необходимости создания АС
а) сбор данных об объекте автоматизации и осуществляемых видах деятельности;
б) оценка качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации;
в) оценка (технико-экономической, социальной и т.д.) целесообразности создания АС.
1.2. Формирование требований пользователя к АС:
а) подготовка исходных данных для формирования требований АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы);
б) формулировка и оформление требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.
2.1. Изучение объекта.
Организация-разработчик проводит детальное изучение объекта автоматизации
2.2. Проведение необходимых научно-исследовательских работ.
а) Организация-разработчик необходимые научно-исследовательские работы (НИР) связанные с поиском путей и оценкой возможности реализации требований пользователя,
б) Оформляется и утверждается отчёт о НИР.
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя:
а) разработка альтернативных вариантов концепции создаваемой АС и планов их реализации;
б) оценка необходимых ресурсов на их реализацию и обеспечение функционирования;
в) оценка преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы.
2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.
Разработка и утверждение технического задания на создание АС.
4. Эскизный проект.
4.1. Разработка предварительных проектных решений по системе и её частям.
а) определяются функции АС; функции подсистем, их цели и эффекты;
б) состав комплексов задач и отдельных задач;
в) определяется концепция информационной базы, её укрупнённая структура;
г) определяется функции системы управления базой данных;
д) определяется состав вычислительной системы;
е) определяется функции и параметры основных программных средств.
4.2. Разработка документации на АС и её части.
Оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС.
5. Технический проект.
5.1. Разработка проектных решений по системе и её частям.
а) разработка общих решений по системе и её частям,
б) разработка функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решения задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
5.2. Разработка документации на АС и её части.
См. п. 4.2
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.
а) подготовка и оформление документации на поставку изделий для комплектования АС;
б) определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно.
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
а) разработка, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.
6. Рабочая документация.
6.1. Разработка рабочей документации на систему и её части.
а) разработка рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение.
6.2. Разработка или адаптация программ.
а) разработка программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации.
7. Ввод в действие.
7.1. Подготовка объекта автоматизации к вводу АС в действие.
а) реализацию проектных решений по организационной структуре АС;
б) обеспечение подразделений объекта управления инструктивно-методическими материалами;
в) внедрение классификаторов информации.
7.2. Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
а) получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий, проводят входной контроль их качества.
7.4. Строительно-монтажные работы.
а) выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС;
б) сооружение кабельных каналов;
в) выполнение работ по монтажу технических средств и линий связи;
г) испытание смонтированных технических средств;
д) сдачу технических средств для проведения пусконаладочных работ.
7.5. Пусконаладочные работы.
а) автономную наладку технических и программных средств,
б) загрузку информации в базу данных и проверку системы её ведения;
в) комплексную наладку всех средств системы.
7.6. Проведение предварительных испытаний.
а) испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний;
б) устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний;
в) оформление акта о приёмке АС в опытную эксплуатацию.
7.7. Проведение опытной эксплуатации.
а) опытная эксплуатация АС;
б) анализ результатов опытной эксплуатации АС;
в) доработку (при необходимости) программного обеспечения АС;
г) дополнительная наладка (при необходимости) технических средств АС;
д) оформление акта о завершении опытной эксплуатации.
7.8. Проведение приёмочных испытаний.
а) испытания на соответствие техническому заданию в соответствии с программой и методикой приёмочных испытаний;
б) анализ результатов испытания АС и устранение недостатков, выявленных при испытаниях;
в) оформление акта о приёмке АС в постоянную эксплуатацию.
8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными обязательствами.
8.2. Послегарантийное обслуживание.
а) анализу функционирования системы;
б) выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений;
в) установлению причин этих отклонений;
г) устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС;
д) внесению необходимых изменений в документацию на АС.

ISOIEC 122071995

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

Основные процессы ЖЦ реализуются ответственным субъектом, вовлеченным в ЖЦ ПС. Ответственным субъектом является одно из юридических лиц (или подразделений, или должностных физических лиц), которые реализуют соответствующий процесс.

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

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

Вспомогательные процессы определяют следующее.

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

Применение требований ГОСТ Р ИСО/МЭК 12207 к конкретному проекту (его адаптация) состоит из работ следующих видов:

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

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

При выборе процессов, работ и задач должны быть определены необходимые для построения модели ЖЦ ПС процессы, работы и задачи. При этом должны быть охвачены разрабатываемая документация и обязанности исполнителей. Дополнительные процессы, работы и задачи, необходимые для реализации проекта, но не описанные в ГОСТ Р ИСО/МЭК 12207, следует установить в договорной документации проекта.

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

Процессы общей структуры ЖЦ ПС по ГОСТ Р ИСО/МЭК 12207 основаны на двух исходных принципах: модульности и ответственности.

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

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

Принцип ответственности:

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

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

В данном стандарте реализованы принципы управления качеством и сделано это тремя основными способами:
1. Интеграция качества в жизненный цикл
ГОСТ Р ИСО/МЭК 12207 устанавливает требования к всеобъемлющему интегрированному набору процессов, охватывающих жизненный цикл программного средства. Указанный стандарт обеспечивает для каждого процесса доступ к циклу "план - реализация - проверка - акт" (plan - do - check - act) посредством процесса усовершенствования. При этом все работы, связанные с качеством и трактуемые как неотъемлемая часть жизненного цикла программного средства, входят в соответствующие процессы жизненного цикла. Таким образом, за каждым процессом и персоналом, отвечающим за его реализацию, закреплены работы в рамках данного процесса, связанные с качеством.
2. Процесс обеспечения качества.
Процесс обеспечения качества (6.3 ГОСТ Р ИСО/МЭК 12207) предназначен для обеспечения соответствия продуктов и услуг конкретным требованиям и установленным планам. Лица, отвечающие за данный процесс, должны быть наделены необходимой организационной независимостью и соответствующими полномочиями. Организационная независимость подразумевает независимость от тех, кто непосредственно отвечает за создание продукта, а соответствующие полномочия подразумевают права на проведение оценки и инициализацию корректирующих действий.
3. Процесс усовершенствования
ГОСТ Р ИСО/МЭК 12207 определяет процесс усовершенствования для дальнейшего повышения качества работ организации в целом независимо от договорных обязательств.

Описание компании

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

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

Моделирование бизнес-процессов подсистемы ведения торгового учета на торговом предприятии

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

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

Функциональное покрытие подсистемы ведения торгового учёта (рис. 7) другими словами это описание функций выполняемых подсистемой. Функциональное покрытие подсистемы было разработано в нотации модели Functional tree, в виде дерева функций – иерархическое деление функций на подфункции.

Рисунок 7 Функциональное представление подсистемы ведения торгового учета

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

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

В качестве входной информации используются следующие наборы данных:
1) Поставщик/Покупатель
a. ИД поставщика
b. Торговое название
c. Геренальный директор
d. Юридический адрес
e. Фактический адрес
f. Расчетный счет
g. Телефон
h. Банк
i. Контактное лицо
j. ИНН
k. БИК

Рисунок 8 Список контрагентов компании

Список контрагентов

Рисунок 9 Карточка контрагента. Вкладка "Общие"

Общие

Рисунок 10 Карточка контрагента. Вкладка "Контакты"

Контакты
2) Накладная
a. Сумма
b. Номер накладной
c. Дата

Рисунок 11 Список накладных

Список накладных
3) Запись списка
a. Количество товара
b. Цена товара
c. НДС

Рисунок 12 Запись списка

Запись списка
4) Склад
a. ИД склада
b. Наименование
c. Адрес
d. Телефон
e. Ответственное лицо

Рисунок 13 Список складов

Список складов

Рисунок 14 Карточка склада

Карточка склада

5) Товар на складе
a. Количество
b. Срок годности

Рисунок 15 Ведомость товара на складе

Ведомость
6) Товар
a. ИД товара
b. Наименование
c. Единица измерения
d. Цена

Рисунок 16 Список товаров

Список товаров

Рисунок 17 Карточка товара

Карточка товара
7) Сотрудник
a. ИД сотрудника
b. ФИО
c. Паспортные данные
d. Должность
e. Телефон

Рисунок 18 Список и карточка сотрудника

Список и карточка сотрудника

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

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

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

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

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

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

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

К ним относятся:

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

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

Метод оценки чистого приведенного эффекта

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

Метод оценки чистого приведенного эффекта
где:
r - ставка дисконтирования (в десятичном выражении);
n - номер года;
О степени эффективности вложения средств в данный проект говорит полученная величина NPV.
Очевидно, что если:
NPV > 0, то проект следует принять;
NPV < 0, то проект следует отвергнуть;
NPV = 0, то проект ни прибыльный, ни убыточный.

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

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

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

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

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

Простой срок окупаемости рассчитывается по формуле 3.

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

где:
PP - срок окупаемости, выраженный в интервалах планирования;
PV - полные инвестиционные затраты проекта;
NCF - чистый эффективный денежный поток за один интервал планирования.

Определение индекса доходности инвестиций

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

Индекс доходности инвестиций PI рассчитывается по формуле 4.

Определение индекса доходности инвестиций

где PV - полные инвестиционные затраты проекта.

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

Экономическая характеристика проектируемой ИС

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

Оценка отрицательных денежных потоков

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

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

Основные поставки продуктов системы «1С:Предприятие 8», содержащие программную часть (технологическую платформу) и прикладные решения для автоматизации различных задач управления и учета (конфигурации), выпускаются в виде однопользовательских продуктов. В комплект основной поставки входит дистрибутив на CD-ROM, комплект документации, однопользовательский ключ защиты от несанкционированного доступа для порта USB, Лицензионное соглашение, разрешающее использование программного продукта на одном компьютере, и другие материалы. Для использования продуктов системы «1С:Предприятие» на двух и более компьютерах в пределах одной локальной вычислительной сети требуется приобретение дополнительных лицензий. Фирмой «1С» выпускаются дополнительные лицензии на 1, 5, 10, 20 и 50 рабочих мест, необходимое пользователю количество рабочих мест складывается из этих лицензий.

Стоимость лицензий следующая:

Исходя из того, что клиентские лицензии можно будет докупить в случае необходимости, то будет достаточно 20 лицензий.
Таким образом, для файлового варианта работы системы затраты могут составить 14 500 + 65 000 = 79 500 (руб.).

Для клиент-серверного варианта потребуется следующее ПО:

Таким образом, для клиент-серверного варианта затраты составят 121 500 (руб.)

Рисунок 19 Диаграмма Ганта

Диаграмма Ганта
В затраты на создание ИС входят затраты на выполнение следующих задач (см. рис. 19):

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

Таблица 4 Расчет стоимости услуг конфигуратора

Расчёт стоимости услуг конфигуратора

Так же необходимо провести обучение персонала, не имевших опыта работы в 1С. Стоимость курса «1С:Предприятие 8. Управление торговлей. Практическое применение типовой конфигурации.» - 6800 руб. Количество сотрудников требующих обучение – 12 человек.

Получаем, 81 600 руб.

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

Оценка положительных денежных потоков

Положительные денежные потоки предполагается получить за счет общего снижения уровня складских запасов и резервных запасов
Рассчитаем возможный доход от изменения складского хранения:
Денежное выражение складских запасов 20 000 000 (руб)
Потенциальное снижение складских запасов – 2%
Экономия активов, вложенных в запасы: 20 000 000 (руб) * 0.02 = 400 000 (руб)
Таким образом, положительные потоки от внедрения проекта составят 400 000 (руб)

Расчет показателей

Использование системы рассчитано на 2 года.
Ставку рефинансирования примем равной 7,75%.

Темп инфляции примем равным 13% в год.
Рассчитаем чистый приведенный доход NPV (см. табл. 5).
Таблица 5 Расчет NPV

Расчет NPV

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

Определим срок окупаемости инвестиций PP:
PP= 303100/400000=0,76 (года)
Таким образом, проект окупит себя за 6 месяцев.

Определим индекс доходности инвестиций PI:
PI= 302 500,78/303100=1,01 (руб)
Т.о. каждый вложенный в проект рубль окупит себя и принесет еще 0,01 руб.

Выводы об экономической эффективности ИС

Проведенный экономический анализ показал, что:

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

Оценка технической составляющей

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

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

Требование для 32 разрядного рабочего сервера кластера серверов:


Требование для 64 разрядного рабочего сервера кластера серверов:


Требование для сервера баз данных:

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

в качестве сервера баз данных может использоваться любой компьютер, на котором может работать Microsoft SQL Server, PostgreSQL или IBM DB2. Технические характеристики компьютера и операционная система должны соответствовать требованиям используемой версии сервера баз данных Microsoft SQL Server, PostgreSQL или IBM DB2.

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

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

Качественные риски – риски, не имеющие прямого денежного выражения.

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

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

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

Количественные риски – риски, которым можно математическую/финансовую оценку.

  1. Упущенная выгода.

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

  2. Риск перерасхода бюджета проекта.

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

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

Заключение

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

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

При проектировании бизнес-процессов подсистемы «Торгового учета» была использована инструментальная среда ARIS Easy Design 7.0. Для раскрытия основ данного case-средства была изучена инструментальная среда ARIS нотации основных моделей.
Для последующего внедрения подсистемы «Торгового учета» был произведен анализ функциональности ERP-системы 1С: Предприятие 8.1 Управление торговлей.

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

Дипломная работа была проделана в целях подготовки данных для последующей разработки подсистемы «Торгового учета» при помощи ERP-системы 1С: Предприятие 8.1 Управление торговлей. Поэтому в последней части работы был произведен плановый расчет экономического эффекта от внедрения данной подсистемы. Для этого были рассчитаны финансовые показатели внедрения системы, такие как чистый приведенный доход от внедрения проекта и cрок окупаемости внедрения проекта. В итоге расчета выяснилось, что внедрение подсистемы «Торгового учета» на торговом предприятии является рентабельным и окупается в течение 9 месяцев.

Также эффективность внедрения была рассмотрена с позиции технической составляющей проекта внедрения. Были разобраны качественные и количественные риски внедрения подсистемы «Торгового учета» при помощи ERP-системы 1С: Предприятие 8.1 Управление торговлей.