История развития КИС

2.1 История развития КИС

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

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

Рисунок 1. История развития корпоративных информационных систем.

2.2 общий вид системной архитектуры

Рис.2 - Общая модель системной архитектуры КИС

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

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

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

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

Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 2).

Рис. 2 - Двухуровневая клиент-серверная архитектура

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

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

Рис. 3 - Трехуровневая клиент-серверная архитектура (Three-tier architecture)

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

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

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

Рис.4 - Распределенная архитектура системы

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

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

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

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

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

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

2.3 Базовая концепция системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Администратор системы, используя комплекс, должен иметь возможность:

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

2.4 Состав системы

Задачи, на решение которых должен быть ориентирован комплекс, могут быть условно выделены в пять функциональных контуров:

  1. контур административного управления;
  2. контур оперативного управления;
  3. контур бухгалтерского учета;
  4. контур управления документооборотом;
  5. контур администратора системы.

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

КАДРЫ

Учет и управление кадрами.

МАРКЕТИНГ

Анализ рынка товаров и услуг. Производители. Цены.

Реклама.

Конкуренты.

Ценовая политика.

Каналы сбыта.

Анализ товарооборота.

ПЛАНИРОВАНИЕ

Календарно-сетевое хозяйственное планирование мероприятий, ресурсов.

Финансовое планирование и управление.

АНАЛИЗ ФИНАНСОВОЙ И ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ

Расчет экономических показателей.

Аналитический баланс.

Контур оперативного управления

УПРАВЛЕНИЕ ЗАКУПКАМИ И ПРОДАЖАМИ

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

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

Управление бартерными операциями.

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

Внутрифирменные складские операции.

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

Управление производством.

Оперативная и аналитическая отчетность.

Контур бухгалтерского учета

БУХГАЛТЕРСКИЙ УЧЕТ

Кассовые операции

Финансово-расчетные операции

Учет материальных ценностей

Учет МБП.

Основные средства и нематериальные активы.

Зарплата.

Дебиторы / кредиторы.

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

Контур управления документооборотом

ДЕЛОПРОИЗВОДСТВО

Управление документооборотом

Регламент и контроль исполнения.

Контур администратора системы

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА

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

Регистрация действия пользователей.

Восстановление баз данных.

Поддержка корпоративного обмена данными.

Экспорт-импорт данных.

Текстовый редактор.

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

Пакет деловой графики.

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

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

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

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

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

История развития КИС