Архивы: по дате | по разделам | по авторам

Автоматизация хаоса-2

Архив
автор : Андрей Акопянц   25.07.2000

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

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

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


Цели корпоративной автоматизации

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

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

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

Имеется два разных класса бизнес-задач, решаемых при внедрении автоматизированных систем.

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

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

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

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

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

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

Эта ситуация достаточно часта, по крайней мере, именно так было в подавляющем большинстве случаев, с которыми мне приходилось встречаться. Дело в том, что экономия на операционных издержках при достаточно дешевом персонале обычно не окупается - часто дешевле нанять лишнюю девочку за 200 долларов в месяц, чем платить 10 тыс. за дополнительный АРМ.

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

Разработка "от данных" - основные принципы

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

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

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

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

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

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

Продолжение следует



© ООО "Компьютерра-Онлайн", 1997-2024
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.