Перед тем как выбрать стратегию автоматизации предприятия (своими или внешними силами внедрить покупные пакеты), нужно подробно изучить предмет автоматизации, результатом чего должна стать информационная модель предприятия.
Существует по крайней мере две (в известной степени противоречащие друг другу) методологии построения информационной модели предприятия. Первая основывается на понятии "устойчивого" бизнес-процесса, тогда как вторая ставит в центр модели обрабатываемые системой данные.
Под устойчивым бизнес-процессом понимается тот технологический аспект деятельности предприятия, который практически не зависит от конкретных технических решений, превратностей законодательства или каких-либо других постоянно меняющихся факторов. Например, к бизнес-процессам относятся прием товара на складе, бронирование (резервирование) товаров клиентам и т. п. Их сущность практически не будет меняться в зависимости от форматов хранения информации о товаре в рамках некоторой принятой концепции, тогда как конкретные типы данных в физической модели могут и измениться.
Таким образом, первая методология построения системы сводится к выделению и формализации устойчивых бизнес-процессов. При этом в процессе алгоритмизации будут зафиксированы и базовые компоненты модели данных: сущности, первичные ключи и т. д.
Далее следует выделение остальных (не базовых или просто более динамичных) бизнес-процессов и описание структур данных информационной системы на их основе либо определение необходимости дополнительной информации о самом бизнесе и построение модели данных уже в этом ключе.
В реальных информационных системах, когда достаточно большой комплекс программ работает с единой БД, сильные изменения структуры данных могут вызвать значительные технические трудности (особенно для настольных СУБД, не имеющих встроенных средств реструктуризации существующих данных).
Вторая методология более характерна для информационных систем сбора и обработки данных, в которых собственно процессы обработки не играют главенствующей роли. Эта модель нетипична для традиционных коммерческих структур, поэтому рассматривать ее подробно мы не будем.
Как же выделить стабильные бизнес-процессы и формально описать их?
Наиболее рациональным выглядит такой подход: процесс деятельности фирмы представляется как черный ящик, получающий что-то на вход, формирующий что-то на выходе, использующий для этого определенные средства управления с соответствующим набором механизмов (по сути это контекстная диаграмма в терминах IDEF0). Следующим шагом является декомпозиция этой диаграммы на независимые процессы; при этом обычно получаются наиболее крупные бизнес-процессы, такие, как прием товара, хранение на складе, продажа товаров, оплата счетов и т. д.
Вообще говоря, эти базовые блоки при дальнейшем проектировании и разработке могут оказаться воплощением рабочих мест соответствующих работников фирмы: складского работника, менеджера по продаже, бухгалтера и др.
"Большая" и "малая" автоматизация
Следует рассмотреть вопрос о классе сложности разрабатываемой и/или внедряемой информационной системы. На наш взгляд, существует два крупных класса так называемых комплексов автоматизации. К первому можно отнести функционально законченный продукт с документированными концепциями (концептуально единый).
Второй класс представляет собой слабо интегрированную систему, не имеющую концептуальной целостности. Ее характерные черты - закрытость, отсутствие модульности и мобильности. Это может быть набор утилит, разрабатываемых и сопровождаемых разными людьми при слабом руководстве, - случай, весьма типичный при неудачном воплощении второго подхода к автоматизации и характерный для крупных и средних постсоветских государственных организаций и предприятий, где автоматизацией занимается бывший отдел АСУ. Подобная ситуация может сложиться и при неупорядоченной закупке у разных поставщиков коммерческих программ, автоматизирующих какую-то малую часть бизнеса (бухгалтерию, складской учет и т. п.) и не имеющих средств интеграции. Последняя проблема, возможно, частично будет ослабляться с появлением таких средств интеграции, как OLE, но пока что она весьма актуальна.
Темой отдельного разговора является комплекс проблем и решений, связанных со сменой автоматизированных систем предприятия с переходом от "легкой" системы к "тяжелой". Очертим лишь круг возможных сложностей:
- перенос имеющихся данных в новую информационную систему;
- совмещение разнородных данных отдельных программ при переходе к новой информационной системе и новой модели данных;
- необходимость переучивания сотрудников фирмы на ходу;
- задача переустановки программного обеспечения в филиалах и прочих подразделениях фирмы, иногда территориально удаленных, обуславливаема заменой набора программ на единый комплекс.
Архитектура информационной системы
Рассмотрим вариант построения информационной системы в плане ее внутренней организации и взаимодействия компонентов.
Разумеется, рассматриваемый вариант не следует воспринимать как единственно возможный, но он позволяет обеспечить те необходимые требования к информационной системе предприятия, которые были рассмотрены выше.
Итак, система строится как набор модулей с делением в горизонтальном и вертикальном направлениях.
В самом нижнем слое следует расположить системно-зависимые компоненты, как-то: работу с СУБД на не зависящем от задачи уровне, обеспечение средств визуализации и т. п. В большинстве случаев для реализации информационной системы на базе IBM PC под управлением Windows в качестве нижнего уровня могут быть использованы стандартные библиотеки доступа и библиотеки классов (ODBC, IDAPI, MFC, OWL и др.).
На следующем уровне находятся реализации бизнес-алгоритмов и компонентов визуализации, специфичных для данной предметной области. При этом реализация бизнес-алгоритмов должна быть выполнена в виде динамически подключаемой библиотеки со стандартными экспортируемыми именами; такой подход позволит использовать реализованные алгоритмы из компонентов вышележащих слоев вне зависимости от используемого для их реализации инструментального средства.
Самый верхний (прикладной) уровень содержит пользовательский интерфейс и "не базовые" бизнес-процессы. Его реализация может быть выполнена как в виде набора исполняемых модулей, соответствующих группам функций или АРМ и библиотекам с алгоритмами, так и в виде единого исполняемого модуля.
Такая схема построения информационной системы позволяет легко добавлять функциональные модули как на второй, так и на третий уровень, обеспечивая высокую степень масштабируемости системы, а зафиксированный интерфейс с нижним уровнем, например, значительно облегчает замену используемой СУБД по сравнению с тем случаем, когда вызовы низкоуровневых функций "размазаны" по всему коду приложения.
Важная проблема, с которой сталкиваются практически все разработчики в процессе автоматизации, заключается в необходимости поддерживать в работоспособном состоянии два варианта системы - сетевую (обычно под этим подразумевается двух- или трехзвенная архитектура клиент-сервер) для центрального офиса компании и однопользовательскую - для ее филиалов или прочих подразделений. При этом для поддержания единой системы отчетности метаданные (структуры хранилищ данных и пр.) должны быть идентичными. В рамках предлагаемой архитектуры эта проблема также может быть решена с минимальными затратами и сводиться к замене ODBC-источника данных с SQL-сервера на какую-либо настольную СУБД. Определенные сложности возникают лишь при переносе серверной части (хранимых процедур, триггеров и т. д.), однако при продуманном выборе пары СУБД (InterBase Server/Local InterBase, Oracle Server/Personal Oracle, Sybase SQL Server/SQL Anywhere и др.) эти сложности могут быть сведены к минимуму.
Игорь Щекалёв
К Игорю Щекалёву можно обратиться по адресу: igor@dtmsoft.msk.ru.
