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

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

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

Введение

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

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

Объект исследования - Страховая компания «ООО СК Согласие»

Предмет исследования - обработка информации о клиентах компании.

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

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

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

1.Основные понятия проектирования информационных систем

1.1. Основные понятия и определения ИС

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

Информация - сведения (сообщения, данные) независимо от формы их представления. [7]

Информационные технологии - процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов. [7]

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

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

Проектирование информационных систем охватывает три основные области:

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

1.2 Этапы проектирования информационных систем

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

Схема классического подхода к разработке информационных систем -- схема «водопада» (рис. 1.1).

информационный программный предметный

Рис. 1.1 - Схема разработки проекта «Водопад»

Формирование требований к системе (Стратегия и Анализ);

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

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

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

2) требуемую пропускную способность системы;

3) требуемое время реакции системы на запрос;

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

5) простоту эксплуатации и поддержки системы;

6) необходимую безопасность.

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

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

Вся информация о системе, собранная на этапе определения стратегии, формализуется и уточняется на этапе анализа.

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

Информация собирается и обрабатывается в двух взаимосвязанных формах:

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

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

Двумя классическими результатами анализа являются:

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

· модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

· диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях; [25]

· диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы; [29]

· диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

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

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

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

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

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

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

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

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

ER-диаграммы.

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

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом1, являются ключевыми (так Title Identity -- ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются) [2].

Рис. 1.2 - ER-диаграмма

Отношение изображается линией между двумя сущностями. Одиночная линия справа означает «один», «птичья лапка» слева -- «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок -- «не обязательно» (Рис. 1.3), например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES [27]. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рис. 1.3 - Элементы ERM

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

Рис. 1.4 - Рефлексивное подчинение

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

Атрибуты сущностей могут быть ключевыми -- они выделяются полужирным шрифтом; обязательными -- перед ними ставится знак «*», то есть их значение всегда известно, необязательными (optional) -- перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными. [4].

Дуги.

Если сущность имеет набор взаимоисключающих отношений с другими сущностями, то говорят, что такие отношения находятся в дуге. Например, банковский счет может быть оформлен или для юридического лица, или для физического лица. (Рис. 1.5) [30].

Рис. 1.5 - Взаимоисключающие отношения

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности -- сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. [35].

Дальнейшим этапом проектирования ИС является логическое и физическое моделирование данных.

Логическая DFD (рис. 1.6) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). [33] Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм. [20].

Рис. 1.6 - Логическая DFD

Диаграммы изменения состояний STD.

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 1.7) Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний [7].

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

Рис. 1.7 - STD-диаграмма

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

· Качество сущностей.

· Качество атрибутов.

· Качество связи.

· Функции системы.

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

Рис. 1.8 - Декомпозиция бизнес процессов

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

Средства разработки ИС можно разделить на несколько групп:

· Средства моделирования;

· Средства прототипирования;

· Средства описания;

· Средства разработки программной части системы;

· Средства разработки баз данных;

· Средства поддержки процесса разработки.

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

В качестве средства разработки информационной системы можно использовать среду 1С [24].

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

«1С» -- не универсальное, а специализированное (предметно-ориентированное) средство разработки. Ни один инструмент не может претендовать на решение всех мыслимых проблем, однако универсальные средства разработки ориентированы на достаточно широкий спектр задач, а платформа «1С» -- на задачи автоматизации бизнеса. [28]

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

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

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

«1С:Предприятие» как предметно-ориентированная среда разработки имеет определенные преимущества. Поскольку круг задач более точно очерчен, то и набор средств и технологий можно подобрать с большей определенностью. В задачу платформы входит предоставление разработчику интегрированного набора инструментов, необходимых для быстрой разработки, распространения и поддержки прикладного решения для автоматизации бизнеса. При этом отдельные «детали» могут уступать по функциональности универсальным средствам разработки и специализированным средствам управления жизненным циклом, используемым разработчиками [3]. Однако эффект достигается благодаря общему набору средств и их тесной интеграции. На рисунке 1.10 представлена среда разработки «1С:Предприятия».

Рис. 1.10 - Многооконная среда разработки «1С:Предприятия»

Платформа «1С:Предприятие» содержит инструменты для выполнения поставленных задач, визуальное описание структур данных, запросов, интерфейса, отчетов, написание и отладка программного кода, профилирование. В ее составе: развитая справочная система, механизм ролевой настройки прав, инструменты создания дистрибутивов, удаленного обновления, сравнения и объединения, диагностика работы приложений, ведения журналов, создания Web-приложений и приложений для КПК, поддержка коллективной разработки, версионирования и пр. Список инструментов, необходимых для поддержки жизненного цикла, не является исчерпывающим [9].

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

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

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

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

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

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

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

2.1 Характеристики предприятия

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

В национальном рейтинге страховых компаний России, проводимом рейтинговым агентством «Эксперт РА» Страховой Компании «Согласие» был присвоен рейтинг надежности А+ ("Очень высокий уровень надежности").

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

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

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

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



Рис. 2.1 - Виды страхования, предлагаемые компанией ООО СК «Согласие»

2.2 Сбор и обработка информации о клиентах страховой компании

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

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

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

- Территориальный;

- Продуктовый;

- Клиентский.

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

- Центральные офисы и филиалы;

- Региональные офисы;

- Дилерские офисы;

- Агенты и брокеры;

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

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

Заказчиками отчетности являются:

- руководство страховой компании;

- управления продаж и клиентского обслуживания;

- управление планирования.

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

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

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

Основные этапы процесса сбора и обработки информации:

- разработка управленческих отчетов в соответствии с требованиями заказчиков;

- настройка необходимых источников данных;

- формирование ежемесячного графика подготовки отчетности;

- загрузка информации из источников, включающая проверку на соответствие установленным форматам;

- реализация расчетов и корректировок;

- публикация.

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

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

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

При выборе конкретной ERP системы для проектирования решения для ООО «СК Согласие» были рассмотрены несколько ERP систем.

Таблица 2.1. Описание систем ERP

Наименование продукта	Фирма-производитель	Краткое описание
R/3	SAP AG www.sap.com	SAP -- безусловный лидер по объемам продаж ПО данного класса в России. Компания держит порядка 40% всего российского рынка ERP-систем. Система R/3 относится к классу крупных интегрированных систем и имеет в своем составе модули, которые существенно расширяют рамки традиционной ERP-системы. Стоимость решения на 50 рабочих мест составляет ориентировочно около $350 тыс Стоимость внедрения как минимум равна стоимости лицензий, а чаще всего в несколько раз превышает ее. Срок внедрения зависит от требуемых функциональных возможностей. Можно сказать, что для российских предприятий он в среднем составляет год-два. Один из наиболее полномасштабных проектов внедрения системы R/3 осуществлен на Омском нефтеперерабатывающем заводе.
Oracle Applications	Oracle www.oracle.ru	Позиции компании Oracle в России существенно слабее, чем у ее основного конкурента. Однако в мире в рейтинге Top100 журнала Manufacturing Systems за 2000 год система Oracle Applications обошла по финансовым показателям R/3 и заняла первое место. Отставание в России можно объяснить отчасти тем, что данное решение значительно позднее вышло на отечественный рынок. Стоимость решения на базе Oracle Applications несколько ниже, чем на базе R/3 (конкретных цифр в открытой печати не приводилось). Срок внедрения у Oracle Applications и R/3 примерно одинаков1. Из наиболее известных проектов внедрения Oracle Applications можно отметить реализованный на Магнитогорском металлургическом комбинате.
Baan IV	Baan www.baan.ru	Еще одна из западных ERP-систем, присутствующих на российском рынке. Класс системы тот же, что и у двух предыдущих. Стоимость именованной лицензии (на одного конкретного пользователя) составляет $3000, стоимость конкурентной лицензии (вне зависимости от количества сотрудников указывает только на ограничения по одновременному подключению к базе данных) -- $6000. Внедрение в России в 1--3 раза дороже стоимости лицензий. Пример реализации - "Нижфарм". К сожалению, в России в настоящее время активно продвигается устаревшая версия системы, несмотря на то, что уже давно появилась версия iBaanERP.
iRenaissance*	ROSS Systems www.rossinc.com	Система ERP-класса для предприятий с процессным (непрерывным) типом производства. Полностью локализована, успешно внедряется в России с 1998 г. В мире - 3500 законченных внедрений, есть внедрения в России (Mary Kay, Alcoa CSI Vostok и др.). Невысокая стоимость и сроки внедрения.*
SyteLine	SYMIX www.frontstep.ru	Данная система относится к классу средних интегрированных систем. Имеет довольно много внедрений на предприятиях пищевой промышленности России. В их числе можно назвать Воронежскую кондитерскую фабрику.
MFG/PRO*	QAD www.qad.com	ERP-система для крупных и средних предприятий с дискретным типом производства. 5200 законченных внедрений в мире, 8 - в России. Полностью локализована. По мнению различных экспертов, система является одним из самых сильных решений для дискретных производств (машиностроение, легкая промышленность, автомобилестроение, электроника и т.д.).*
"ПАРУС"	Корпорация "Парус"www.parus.ru	Относится к классу финансово-управленческих систем. С точки зрения производства имеет возможности учета и простейшего планирования. Традиционно очень сильны позиции корпорации в бюджетных организациях.
"Галактика"	Корпорация "Галактика"www.galaktika.ru	Данная система является лидером среди российских систем управления предприятием. По отдельным оценкам, ее доля составляет около 40% от всех российских поставщиков. По объемам продаж система уступает только R/3.Срок внедрения сильно зависит от выбранной функциональности и масштабов предприятия. Например, внедрение 100 рабочих мест на ОАО "Русский продукт" заняло около полутора лет.
"БОСС-Корпорация"	Компания "АйТи" www.it.ru	Интеграция учетных функций с производственной системой позволит данному продукту ускорить переход к классу средних интегрированных систем. Из наиболее успешных проектов отмечается проект по созданию системы управления финансами на Красноярском алюминиевом заводе.
"1С:Производство"	Компания 1С www.1c.ru	Хотя продукция компании 1С относится к классу локальных систем, не отметить данного игрока нельзя. В своем классе 1С занимает лидирующее положение, далеко опережая конкурентов. В составе продукции 1С есть и система "1С:Производство", которая позволяет в некотором объеме решить задачи производственного учета и планирования.

Как видно из этой таблицы 2.1, спектр возможных решений довольно велик. Следует отметить, что для современных ERP-систем характерно развитие новых функциональных возможностей, связанное с выходом за традиционные рамки оптимизации и автоматизации транзакционных процессов внутри предприятия. В основном это касается автоматизации логистических цепочек (так называемые процедуры Supply Chain Management, SCM -- управление цепочками поставок) и взаимоотношений с клиентами (Customer Relationship Management, CRM -- управление взаимоотношениями с клиентами). [10] При этом традиционный контур управления, присущий ERP-системе, теперь называют приложениями back-office (или внутренней системой), а расширения, направленные "наружу" предприятия, - приложениями front-office. Все это дало повод компании Gartner Group сначала заявить о том, что эпоха ERP-систем завершилась в 1999 году, а затем выдвинуть новую концепцию управления - обработка внешних и внутренних данных предприятия (Enterprise Resource and Relationship Processing, или ERPII).

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

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

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

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

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

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

Анализ потребностей заказчика показал, что оптимальной системой для заказчика является 1С:ERP Управление предприятием 2.

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

2.3 Обзор системы «1С:Предприятие 8

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

Рис. 2.2 - Верхний уровень структуры «1С:Предприятие»

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

· Прикладные программные решения (конфигурации), которые были спроектированы на её базе;

· Внедрение разработанных конфигураций.

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

2.4 Технология разработки программной системы 1С

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

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

· Изменение интерфейса пользователя: 1С: Предприятие 8.3 имеет новый и более функциональной архитектурой работы клиент-сервер);

· Модернизирован и оптимизирован процесс инсталляции, запуска и актуального обновления программной платформы 1С: Предприятие 8.3;

· Версия 8.3 стала существенно более удобной для внедрения этой системы в крупные компании;

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

Таким образом, 1С идеально подходит в качестве платформы для проектирования ИС для ООО «СК Согласие». [16]

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

2.5 Этап тестирования, ввода в действие, эксплуатация

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

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

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

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

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

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

3. Проектирование информационной системы для ООО «СК Согласие

3.1 Задачи проекта

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

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

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

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

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

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

3.2 Стратегия развертывания системы

Стратегия развертывания системы предусматривает:

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

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

Проектные ограничения (матрица компромиссов).

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

· Функциональность (требования к функциям, возможности).

· Бюджет проекта (ресурсы).

· Срок исполнения проекта (время).

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

Возможны такие логические взаимосвязи:

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

· Зафиксировав ресурсы, мы согласовываем функциональность решения и принимаем результирующие сроки.

· Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки.

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

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

· Зафиксировав сроки, мы согласовываем объем функциональности решения и принимаем результирующие затраты ресурсов.

Таблица 3.1. Матрица компромиссов для Проекта

	Фиксируется	Согласовывается	Принимается
Ресурсы		1
Время	1
Функциональность			1

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

Результат Проекта.

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

Готовность системы к эксплуатации определяется по результатам тестирования совместно представителями Исполнителя и Заказчика. Оценка готовности утверждается Управляющим комитетом Проекта.

Проектирование баз данных в среде 1С.

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

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

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

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

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

Можно моделировать строение базы данных, используя хорошо известные диаграммы «сущность-связь» ERD (Entity-Relationship Diagrams) в нотациях Чена (Chen) или Баркера (Barker). Но интерпретировать разнообразные типы объектов 1С как простые таблицы было бы ошибочным упрощением. Подобные модели (например, довольно распространенные модели в нотациях IDEF1X (Integration Definition for Information Modeling) и IE (Information Engineering)) ориентированы на проектирование реляционных баз данных, в то время как базы, разработанные на платформе 1С, вообще говоря, таковыми не являются. Более того, одним из ключевых объектов 1С является «документ», предназначенный для отражения хозяйственных событий предприятия.

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

Для моделирования документооборота (в широком смысле) удобны диаграммы потоков данных DFD (Data Flow Diagrams). Традиционно для изображения DFD используются две нотации: Йодана (Yourdon) и Гейна- Сарсона (Gane-Sarson). Однако нужно понимать, что DFD - это средство, скорее предназначенное для моделирования функциональных требований системы, которая представляется в виде сети функциональных компонент, связанных потоками данных. В нашем же случае речь идет о графическом отображении структуры данных, желательно с учетом особенностей идеологии 1С.

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

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

Связи (рисунок 3.1)

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

· Связь 2 - между подчиненными справочниками.

· Связь 3 - между регистром и регистратором (документом, осуществляющим движение данного регистра) (Рис. 3.1).



Рис. 3.1 - Сущность связей

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

· Вертикальная композиция: объекты одного типа по возможности располагаются одним столбцом.

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

3.3 Прототипирование интерфейса

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

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

При входе в систему пользователь попадает на главный экран системы. Экран представляет собой совокупность форм, объединяющих элементы интерфейса - user controls (рис. 3.2).