Информационное хранилище на современном предприятии это прежде всего интеллектуальная составляющая, которая представляет собой совокупность информационных систем, включая баз данных и справочников, реализующих функциональность по описанию метаданных, по сбору, очистке, обогащению, консолидации первичной информации из транзакционных систем, а также по построению витрин данных.
По хранилищам данных обычно собирается следующая информация: среднее количество записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из процессов, включающих перечисленные действия. Проектировщик баз данных может использовать эту статистику для нескольких целей – например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа и т.д. Более того, к этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую частоту и / или гибкость доступа к данным
Отчётность представлена совокупностью информационных систем, включая базы данных и справочники, автоматизирующих построение отчётности на основе данных из информационного хранилища.
Примеры систем отчётности:
· система управленческой отчётности,
· система аналитической отчётности,
· система ключевых показателей эффективности подразделений предприятия,
· система формирования показателей для расчёта скорингового балла по кредитной заявке.
Все это является неотъемлемой частью современного предприятия, которое перешло в новую по отношению к предприятиям XX века. Оно стало электронным, или как говорит Бил Гейтс: «Перешло на электронные рельсы».
Вот это и есть самое главное изменение в деловой окружающей среде – сама природа организации и управления. Появились новые возможности для в данном направлении. Некоторые фирмы начали пользоваться преимуществом этих новых возможностей.
Традиционная деловая фирма была и все еще является иерархическим, централизованным, структурным построением специалистов, что естественно при установленном наборе стандартной эксплуатационной техники, чтобы производить серийно изделие (или обслуживание). Новый стиль деловой фирмы сглажен (менее иерархический), децентрализован, имеется гибкое распределение управляющих, которые полагаются на почти мгновенную информацию, чтобы поставлять массовые изделия и услуги, однозначно подходящие для определенных рынков или клиентов. Этот новый стиль организации еще нетвердо укрепился – он все еще развивается. Однако направление ясно, и это новое направление было бы невозможным без информационных технологий.
Традиционная группа управления действовала и все еще работает на формальных планах, твердом разделении труда, формальных правилах и поддерживает порядок, чтобы гарантировать обычное функционирование фирмы. Новый менеджер ориентирован на неформальные обязательства и сети, чтобы установить цели (вместо формального планирования), гибкое расположение групп и личностей, образующих целевые команды, ориентацию на клиента, чтобы достигнуть координации среди служащих, и обращение к профессионализму и знанию, чтобы гарантировать непрерывное развитие фирмы. Именно информационные технологии, делают возможным этот стиль управления.
Информационные технологии вызывают изменения в организации, которые делают фирму даже более зависимой, чем в прошлом, от знания, изучения и принятия решений индивидуально служащими.
В центре любой методологии находится некоторая системная архитектура, и лишь затем совокупность стратегий и методов анализа и проектирования. Архитектура современных систем является трехслойной (рис. 2) и имеет следующие характеристики:
· четко определенные слои
· формальные и явные интерфейсы между слоями
· скрытые и защищенные детали внутри каждого слоя.
| ПОЛЬЗОВАТЕЛЬ |
| ДОКУМЕНТЫ |
| ПРАВИЛА БИЗНЕСА |
| ДАЗА БАННЫХ |
| ОПЕРАЦИОННАЯ СИСТЕМА |
Рисунок 2. Архитектура современных систем
Три слоя (база данных, правила бизнеса, документы) отражают возрастание уровня абстракции в рассматриваемой системной архитектуре. Наиболее детальным слоем является база данных, более высокий уровень абстракции – слой правил бизнеса, наивысший уровень абстракции – слой документов. В данной архитектуре слой правил бизнеса является относительно новой концепцией, соответствующей функциям руководителей среднего звена. Процессы данного слоя отражают:
· выполнение требуемых задач
· принятие решений в соответствующей компетенции
· запуск других задач в слое правил бизнеса и других слоях.
Независимость слоев трехслойной системной архитектуры обеспечивает следующие основные преимущества:
· улучшение базы данных – отделение базы данных от изменений в технологиях, а следовательно, поддержка согласованности и осмысленности данных в течении длительного периода времени;
· гибкость интерфейсов пользователя – изменение интерфейсов без влияния на бизнес-процессы и наоборот;
· разделение усилий коллектива разработчиков.
Трехслойная архитектура (а именно, выделение слоя бизнес-правил) требует модификации существующих методологий, в первую очередь, информационно-ориентированных методологий и методологий, ориентированных на данные. Такие методологии имеют следующие две характеристики, нуждающиеся в изменении:
· информационная модель (и база данных) рассматриваются как центральные понятия при анализе и проектировании;
· функциональная модель (а следовательно, и правила бизнеса) является некоторым дополнением к информационной модели.
Согласно такому подходу, информационная модель является первичной, занимает центральное место и регламентирует весь процесс анализа и проектирования, что приводит к следующим ограничениям:
· построенная на ее основе функциональная модель либо является слабо связанной с информационной моделью, либо неадекватно отражает существующие бизнес-процессы и правила;
· сама по себе информационная модель является недостаточной (хотя и важной) для решения задач консалтинга;
· информационная модель плохо понимаема неспециалистами, поэтому попытки вовлечь руководство в разработку обречены на неудачу.
С другой стороны, руководство прекрасно ориентируется в технологиях и бизнес-процессах предприятия. Более того, функциональные модели (например, на базе диаграмм потоков данных) интуитивно понимаемы неспециалистами.
Таким образом, в центре современного проекта лежат две вещи – база данных и бизнес-процесс. При этом основным центром является бизнес-процесс, база данных – менее важный из двух центров, т.е. процесс становится первичным и во многом определяет весь проект. Модель процесса является ценным средством для размышлений и совместной работы над перспективами развития предприятия и системной разработкой. Тем не менее информационная модель продолжает оставаться важной и соответствующим образом влиять на разрабатываемую функциональную модель.
В таблице 1 представлена трехслойная системная архитектура в разрезе регламентируемых методологией этапов разработки (анализ требований, проектирование, реализация).
Таблица 1. Системная архитектура
| Слои | Анализ | Проектирование | Реализация |
| Документы | Поток работ | Поток форм | Формы |
| Правила бизнеса | Поток процессов | Модель компонентов | Программы |
| База данных | Модель данных | Схема базы данных | Таблицы и т.п. |
Анализ требований. В слое документа рассматриваются обобщенные потоки между подразделениями и конкретными сотрудниками предприятия без подробного описания каких-либо учетных форм и интерфейсов. На уровне правил бизнеса рассматриваются детальные модели требований. На уровне базы данных строится концептуальная модель, увязанная с функциональной моделью требований на уровне укрупненных подсхем будущей информационной модели.
Проектирование. На уровне документа макетируются последовательности форм. На уровне бизнес-правил осуществляется детальное проектирование будущих рабочих мест с привязкой к конкретным сущностям информационной модели. На уровне базы данных концептуальная модель преобразуется в диаграмму «сущность-связь».
Реализация. На данном этапе проект преобразуется в систему.
В следующей главе рассматривается методология выполнения консалтинговых проектов, адаптированная для трехзвенной архитектуры прежде всего за счет ее ориентации на первичность правил бизнеса.
Спецификация процесса (СП) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD (т.е. если он достаточно невелик, и его описание может занимать до одной страницы текста). Фактически СП представляют собой алгоритмы описания задач, выполняемых процессами: множество всех СП является полной спецификацией системы. СП содержат номер и / или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.