Учебная работа. Реферат: Методология разработки автоматизированной информационной системы

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (5 оценок, среднее: 4,80 из 5)
Загрузка...
Контрольные рефераты

Учебная работа. Реферат: Методология разработки автоматизированной информационной системы

План

Введение

1. разработка разработки АИС

2. Способы проектирования АИС

3. Стадии и этапы сотворения АИС

4. Языки программирования

5. Заключение

Введение

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

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

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

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

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

2) информационный фонд системы;

3) методы и способы организации действий обработки инфы;

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

5) комплекс технических средств, функционирующих в системе;

6) персонал, обслуживающий систему [1].

Главными целями автоматизации деятельности компании являются:

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

3. Автоматизация действий, обеспечивающих выполнение главный деятель.

1. Разработка разработки АИС

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

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

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

разработка обязана очень отражать все этапы цикла жизни проекта;

• разработка обязана обеспечивать малые трудовые и стоимостные Издержки на проектирование и сопровождение проекта;

разработка обязана содействовать росту производительности труда проектировщиков; • разработка обязана обеспечивать надежность процесса проектирования и эксплуатации проекта;

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

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

По степени автоматизации различают:

• ручное проектирование, при котором проектирование компонент АИС осуществляется без использования особых инструментальных программных средств; программирование делается на алгоритмических языках;

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

По степени использования типовых проектных решений различают:

• оригинальное (личное) проектирование, когда проектные решения разрабатываются «с нуля» в согласовании с требованиями к АИС;

• типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программных модулей).

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

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

• реконструкция – адаптация проектных решений производится методом переработки соответственных компонент (перепрограммирования программных модулей);

• параметризация – проектные решения настраиваются в согласовании с данными и изменяемыми параметрами;

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

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

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

Промышленность разработки автоматических информационных систем управления родилась в 50-х — 60-х годах и к концу века заполучила полностью законченные формы. Материалы данного управления являются обобщением цикла лекций по Автоматическим Банковским Системам (АБС) и Автоматическим системам управления конструкторско-технологическим проектированием (АСУ КТП), читаемым в МГТУ им.Н.Э.Баумана. Не глядя на имеющиеся различия в реализации многофункциональных модулей данных систем, общие подходы к их разработки почти во всем идентичны, что позволило нам соединить вопросцы их проектирования в рамках 1-го издания.

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

2.1 способ «снизу-вверх».

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

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

2.2 способ «сверху-вниз».

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

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

Развитие банковских структур и промышленных компаний, повышение числа филиалов, рост количества клиентов, необходимость увеличения свойства обслуживания предъявляли к автоматическим системам новейшие требования. Новейший подход к проектированию АИС заключается в равновесном сочетании 2-ух прошлых. Сначала это относилось к идеологии построения ядра системы: «Автоматическая бухгалтерия — аналитический учет».

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

· формирование всех нужных бухгалтерских проводок, уже агрегированных по балансовым счетам, и автоматическая их передача в базу данных «Автоматической бухгалтерии»;

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

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

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

Задачка проектирования АИС промышленных компаний наиболее сложна, т.к. нрав обрабатываемой инфы еще наиболее разнороден и трудно формализуем. Но и тут можно выделить основную модель работы — это работа «от кода проекта». В общем случае код проекта представляет собой аналог (многофункциональный) лицевого счета, он имеет определенную разрядность, порядок (т.е. определенная группа цифро-буквенного обозначения охарактеризовывает деталь, сборочную единицу, изделие и их уровень связи). При этом определенная часть кода охарактеризовывает технологические, конструкторские, денежные и др. документы. Все это регламентируется надлежащими ГОСТами (аналог инструкций ЦБ для банков), потому быть может формализовано. При всем этом модульный подход к реализации АИС в этом случае еще наиболее важен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Стадии и этапы сотворения АИС.

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

Стадия 1. Формирование требований к АИС:

• обследование объекта и обоснование необходимости сотворения АИС;

• формирование требований юзеров к АИС;

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

Стадия 2. Разработка концепции АИС:

исследование объекта автоматизации;

• проведение нужных научно-исследовательских работ;

• разработка вариантов концепции АИС, удовлетворяющих требованиям юзеров;

• оформление отчета и утверждение концепции.

Стадия 3. Техническое задание:

• разработка и утверждение технического задания на создание АИС.

Стадия 4. Эскизный проект:

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

• разработка эскизной документации на АИС и ее части.

Стадия 5. Технический проект:

• разработка проектных решений по системе и ее частям;

• разработка документации на АИС и ее части;

• разработка и оформление документации на поставку девайсов изделий;

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

Стадия 6. Рабочая документация:

• разработка рабочей документации на АИС и ее части;

• разработка и адаптация программ.

Стадия 7. Ввод в действие:

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация АИС поставляемыми изделиями (программными и тех- ническими средствами, программно-техническими комплексами, информа- ционными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение подготовительных испытаний;

• проведение опытнейшей эксплуатации;

• проведение приемочных испытаний.

Стадия 8. Сопровождение АИС:

• выполнение работ в согласовании с гарантийными обязанностями;

• послегарантийное сервис.

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

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

Материалы, приобретенные в итоге обследования, употребляются для:

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

• разработки технического и рабочего проектов систем.

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

Примерное содержание ТЭО:

• ограничения, опасности, критичные причины, которые могут воздействовать на удачливость проекта;

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

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

• описание выполняемых системой функций;

способности развития и модернизации системы;

• интерфейсы и распределение функций меж человеком и системой;

• требования к ПО и системам управления базами данных (СУБД).

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

Аналитики собирают и фиксируют информацию в 2-ух взаимосвязанных формах:

• функции – информация о событиях и действиях, которые происходят в автоматизируемой организации;

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

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

• наименование задачки; сроки и периодичность ее решения;

• степень формализуемости задачки;

• источники инфы, нужные для решения задачки;

характеристики и их количественные свойства;

• порядок корректировки инфы;

• действующие методы расчета характеристик и вероятные способы контроля;

• действующие средства сбора, передачи и обработки инфы;

• действующие средства связи;

• принятая точность решения задачки;

• трудозатратность решения задачки;

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

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

При обследовании документооборота составляется схема маршрута движения документов, которая обязана отразить:

• количество документов;

пространство формирования характеристик документов;

• связь документов при их формировании;

• маршрут и продолжительность движения документа;

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

• внутренние и наружные информационные связи;

• размер документа в знаках.

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

Заключение

Создание АИС содействует увеличению эффективности производства экономического объекта и обеспечивает свойство управления.

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

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

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

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

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

— улучшение значений характеристик свойства обработки инфы (увеличение степени достоверности обработки инфы, степени ее защищенности, увеличение степени автоматизации получения первичной инфы);

— повышение числа обслуживаемых клиентов.

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

— во всех подразделениях и в организации в целом вводится унифицированная, формализованная и строго регламентированная разработка делопроизводства;

— организация становится вполне управляемой. Возникает возможность ответить на хоть какой вопросец по документам и исполнителям, производить анализ и управление документационной Деятельностью;

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

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

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

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

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

]]>