VI. АСУ как исторически основной тип автоматизированных систем
Хотя аббревиатура АС – автоматизированные системы управления на протяжении многих, предшествующих 90-м прошлого века, была «брэндом» всего семейства автоматизированных систем, АСУ не оправдали всех надежд, теоретически с ними связанных. Они не имели успеха по ряду причин.
Во-первых, реализовывались на слишком дорогой и ненадежной вычислительной технике.
Во-вторых, проектировались во времена натурального хозяйства, когда каждое ведомство разрабатывало собственную систему с учетом специфики отрасли, в результате чего получались плохо отлаженные, абсолютно закрытые и непереносимые с одной аппаратной платформы на другую продукты.
В-третьих (и это, по-видимому, самое главное), в их функционировании не были заинтересованы руководители среднего звена.
По мнению Б.В.Дроздова причины кризиса (и даже трагедии АСУ), не в низком качестве отечественной вычислительной техники. Она была по тому времени не хуже и не лучше зарубежных образцов. Были даже очень неплохие отечественные ЭВМ, особенно выполненные по военной приемке (например, Минск-23). Очень удачной была серия ЭВМ БЭСМ-6 с уникальной отечественной операционной системой ОС ДИСПАК. ЭВМ этого типа еще совсем недавно успешно в течение не одного десятка лет работала в ВЦ Гидрометеоцентра. Трагедия АСУ – в трагедии общественно-политической и экономической системы, под требования которой создавались эти АСУ. Если оказалась полностью разрушена вся система управления (министерства, главки, тресты, как союзные, так и республиканские), все органы планирования и экономического управления, то и все созданные для них АСУ оказались не нужными. Если разваливались отечественные предприятия, то и их АСУП и АСУ ТП были выброшены за ненадобностью. Выжили только те АС, которые обеспечивали работу систем жизнеобеспечения, которые просто побоялись разрушать новые власти. Это АСУ водоснабжения, газоснабжения, теплоснабжения и (на начальном этапе), - электроснабжения, а также ряд АСУ социальной сферы.
Эпоха разработки и разочарований в гигантских, всеобъемлющих АСУ прошла, их сменили многочисленные разрозненные программы, предназначенные для автоматизации отдельных видов деятельности. Больше всего повезло области автоматизации учета, для которой в настоящее время созданы сотни программ. Увы, значительная их часть построена на базе настольных СУБД и абсолютно не допускает масштабирования (перенесения на ЭВМ других и классов). Зачастую невозможно какое-либо взаимодействие между различными программами, и результаты работы системы, функционирующей в одном отделе или управлении, распечатываются и передаются в другое подразделение, где вновь вводятся в компьютеры. Решение проблемы наведения порядка в программах автоматизации практически всегда зависит лишь от руководителя.
В большинстве государственных и муниципальных организаций подразделения для решения похожих задач используют разные, иногда несовместимые между собой системы, и не всегда даже задумываются об интерфейсах между ними и стандартизации представления информации. Многие предприятия преувеличивают уникальность своих задач. Анализ показал, что системы автоматизации управления на 80% состоят из одних и тех же функций. Сведение этих функций в интегрированную систему автоматизации деятельности является далеко нетривиальным процессом. Но это как бы заход с другой стороны. По-настоящему такую систему необходимо проектировать изначально. В этой связи все чаще используется термин «корпоративная автоматизированная информационная система предприятия».
Процесс компьютеризации российских предприятий и организаций проходит достаточно единообразно, что позволяет выделить в нем ряд основных этапов. При этом на каждом из этапов заказчик в лице руководителя организации или подразделения употребляет термин «автоматизация», под которым подразумевается некое многоликое и всеобъемлющее понятие. Первые ростки автоматизации на многих предприятиях связаны с появлением персонального компьютера, с помощью которого решались простейшие расчетные задачи и подготавливались документы. Он, по сути, выполнял роль интеллектуальной пишущей машинки. Возможность создания удобного интерфейса, облегчающего общение с ПК, породила множество однопользовательских приложений, задачей которых было проведение конкретного расчета в соответствии с внутренними требованиями компании или вышестоящей организации.
По мере насыщения отдела персональными компьютерами возникла потребность обмениваться уже подготовленными, т.е. напечатанными кем-то, документами, а затем решать и более сложную проблему подготовки документа несколькими пользователями. Наступает эпоха файл-сервера.
Эту концепцию легко принимает конечный пользователь. Вкусив лишь первые плоды тотальной компьютеризации и узнав, что можно обойтись без перепечатки документов на пишущей машинке или получать готовую расчетную форму, просто задав «умной» системе несколько значений, он все же хотел бы сохранить некий материальный эквивалент того, что делает. Вероятно, именно этим объясняется тот факт, что даже при наличии сети один и тот же документ тиражируется на ПК множества пользователей, а зачастую и переносится просто на дискете.
Тем временем в организациях автоматизируются все новые и новые отделы в обычной последовательности - бухгалтерия, склад, отдел продажи т. д. Для каждого из них создаются свое приложение, своя сеть ПК. Но из-за разброса во времени автоматизации того или иного отдела используются разные инструментальные средства (языки), а данные сохраняются в разных форматах.
Однако любая организация - это единое целое, и отделы должны обмениваться данными друг с другом. На первых этапах обмен осуществляется через совместно используемые файлы. Постепенно, по мере автоматизации очередных подразделений, их данные все больше интегрируются между собой, а информационные системы объединяются, превращаясь в информационную систему организации - именно ее и называют корпоративной информационной системой.
В результате предприятие становится заложником "монстра"- автоматизированной информационной системы, которая требует вложения средств в быстродействующие сети, увеличения штата сотрудников для поддержки существующих и разработки новых приложений, необходимость в которых возрастает, так как все большее число работников вовлекается в сферу действия информационной системы.
Именно на этом этапе встает вопрос о создании такой современной информационной системы, в которой (учитывая предыдущий печальный опыт) были бы заложены возможности дальнейшей модернизации. Специалисты начинают изучать рынок в поиске средств для peaлизации этой цели.
Принятие решения о разработке новой информационной системы или модернизации существующей невозможно без предварительного анализа модели функционирования предприятия, в которой, как на карте, отображается взаимодействие отделов, рабочих групп и конечных пользователей, необходимое для выполнения ими своих должностных обязанностей. Эту модель называют моделью деловых процессов (бизнес-процессов), и для ее построения используются специальные методологии, помогающие формализовать все основные аспекты деятельности сотрудников организации - нотации для построения бизнес-моделей. Наиболее простой и интуитивно понятной представляется авторская ПОСТ-нотация, прошедшая многолетние успешные испытания в десятках разработок. Основная цель построения бизнес-моделей - выявить и представить в виде диаграмм рабочие процессы и данные, с которыми работают сотрудники. Затем необходимо перенести эти данные в концептуальные модели баз данных, которые отображают расположение данных на вычислительных средствах организации и их взаимосвязь.
При выборе средств моделирования данных и моделирования процессов специалисты, занимающиеся автоматизацией предприятия, часто делают акцент на первом варианте, не учитывая, что структуризация данных в информационной системе определяется потребностями конечных пользователей, другими словами, бизнес-процессами предприятия. Руководителей больше всего интересует интегрированная модель процессов, которая позволяет им увидеть функционирование собственной организации, помогает понять, все ли взаимосвязи в ней верны и есть ли возможности улучшить работу предприятия в целом.
Поэтому часто можно наблюдать следующую картину.
Руководство крупных организаций заказывает проведение обследования с целью построения модели процессов. Естественно, при выборе инструментария предпочтение отдается продуктам, ориентированным на моделирование процессов в то же время имеющих в своем классе невысокую стоимость. После широкомасштабных обследований в организации остаются пухлые тома моделей, понять которые могут только их авторы. Практическая реализация проделанной работы, например в форме оптимизации существующих приложений, отсутствует. С другой стороны, начальники отделов автоматизации, чья деятельность по определению связана с работой над моделями данных, выбирают средства именно этой категории. В результате создание новых и модернизация существующих приложений осуществляются без учета взаимодействия приложений и данных в организации в целом. Во многом преодолеть этот недостаток позволяет использование ПОСТ-нотации, как методологии разработки интегральных моделей корпоративной деятельности .
Компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» пришла к следующим неутешительным выводам.
«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%».
Кто виноват в этом? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике разработки АС, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».
Что делать? Управлять людьми. Успех, а равно и провал, проектов по разработке АС на 100% лежит в области психологии.
Проектирование автоматизированной системы, как любой системы, проводят в соответствии с этапами жизненного цикла АС. Прежде чем переходить к рассмотрению работ, выполняемых по стадиям и этапам жизненного цикла разработки АС, рассмотрим подробнее понятие жизненного цикла системы.
|
