Информационные системы в экономике (стр. 14 из 20)

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

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

· В четвертых, оперативная реакция на изменения правил игры на рынке.

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

Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам собственные разработки АИС в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД.

Во-вторых, использование при разработке современного инструментария (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т.п.).

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

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

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

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

4.2 Этапы разработки автоматизированных информационных систем.

Таблица 3.Этапы проектирования АИС и их характеристики.

№	Наименование этапа	Основные характеристики
1	Разработка и анализ бизнес - модели	Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС.
2	Формализация бизнес - модели, разработка логической модели бизнес -процессов.	Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
3	Выбор лингвистического обеспечения, разработка программного обеспечения АИС.	Разработка АИС: выбирается лингвистическое обеспечение (среда разработки - инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы - в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС.
4	Тестирование и отладка АИС	На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.
5	Эксплуатация и контроль версий	Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

Рис.2. Последовательность трансформации бизнес-модели в объекты БД и приложения.

Разработка и анализ бизнес-модели

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

· Получения информации;

· Переработка информации;

· Анализа, подготовки и принятия решения.

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

· руководство теряет целостную картину происходящего;

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

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

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

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

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

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

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