Целевая функция автоматизируемого объекта

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

   Опустимся чуть ниже и посмотрим, какими операциями с документами сопровождается упомянутый процесс.

   Начало тривиального цикла

   Чтобы купить, необходимо:
   а) узнать, какой товар есть на рынке;
   б) выбрать необходимый товар;
   в) заключить договор на покупку нужного товара;
   г) оплатить товар;
   д) оприходовать товар на складе.
   . . . . . . . .

   Чтобы продать:
   е) найти покупателя на товар;
   ж) подготовить договор на продажу;
   з) получить оплату в соответствии с договором;
   и) отпустить товар со склада.

   Конец тривиального цикла.

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

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

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

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

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

   Тем не менее получить любой вторичный документ мы можем только в том случае, если нам будет одновременно доступен весь набор данных.
   Значит, в систему должны быть введены ВСЕ данные.

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

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

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

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

   Определившись с базой данных, рассмотрим вопрос о количестве и размещении компьютеров.
   Естественно, что использование единой базы данных требует коммуникаций между всеми компьютерами и сервером. В настоящее время эти возможности предоставляет локальная сеть, а также "всемирная паутина".
   Однако по мере развития предприятия может потребоваться включить в сеть больше компьютеров, чем может обслужить сервер на базе персонального компьютера.
Выход из этой ситуации достаточно очевиден - переход на новую компьютерную платформу. Иногда сделать это не просто, если переход потребует смены привычного  программного обеспечения и переобучения персонала.
   В связи с этим активно обсуждаются вопросы мобильности программного обеспечения.
Проблема эта не нова. В каком-то смысле нашей стране повезло, что компьютеры не являлись необходимым элементом в производственной жизни предприятий.
На предприятиях развитых стран в недрах Big Blue хранятся огромные объемы данных, сформированные программами, написанными на языке Cobol, ныне почти забытом и непочитаемом молодыми программистами.
   Для примера, на одной из первых московских станций технического обслуживания автомобилей Mersedes установлен такой программный комплекс.
   Помимо весьма скудных интерфейсных средств и возможностей отображения информации на экране, он отличается весьма не высокими быстродействием и надежностью.
   Когда у главного программиста фирмы-производителя автомобилей поинтересовались, почему они используют столь устаревшую программу, он ответил, что проблема не в том, чтобы написать новую хорошую программу, а в том чтобы научить ее использованию персонал 50 000(!) станций во всем мире.

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

Приобрести книгу можно в интернет-магазине Озон  https://ozon.ru/t/p5D2PQC
;