Содержание к диссертации
Введение
Глава 1 . Информационная инфраструктура предприятия 10
1.1. Модели управления предприятием 10
Понятие хранилища данных 12
Хранилище данных и модели управления 13
1.2. качеством информации Подходы к управлению 18
1.3. Метамодели информационной инфраструктуры 21
1.4. Постановка задачи диссертационного исследования 36
Глава 2. Моделирование хозяйственной деятельности 44
2.1. Балансовая модель предприятия 44
2.2. Согласование "бизнес-номенклатуры" моделей оперативных источников и модели предприятия 66
2.3. Выводы по главе 2 81
Глава 3. Практическая реализация подхода 84
3.1. Описание методики проектирования 84
3.2. Применение балансового метода для решения задач снабжения. 98
3.3. Построение балансовой модели предприятия с помощью программного продукта Система АЛЕФ 117
3.4. Результаты практической реализации балансового метода... 127
3.5. Выводы по главе 3 132
Заключение 134
Результаты диссертационного исследования 134
Перспективы исследования 134
Двойная запись и активная модель предприятия 136
Литература 140
Приложения 147
- качеством информации Подходы к управлению
- Согласование "бизнес-номенклатуры" моделей оперативных источников и модели предприятия
- Применение балансового метода для решения задач снабжения.
- Построение балансовой модели предприятия с помощью программного продукта Система АЛЕФ
Введение к работе
Актуальность и степень разработанности проблемы исследования.
Возрастающая динамика и сложность рыночных отношений, жесткие условия рыночной конкуренции, в которых находится большинство предприятий, требуют все более оперативной информации для поддержки принятия решений. При этом успех предприятий в большой степени зависит от того, насколько качественна информация, предоставляемая управляющим для анализа, выработки альтернатив и принятия решения.
Прежде чем информация из разрозненных источников может быть использована для поддержки принятия решений, она претерпевает сложный цикл обработки.
Первичный сбор и обработка данных в рамках информационной инфраструктуры предприятия осуществляется в оперативных источниках, которые накапливают их в базах данных и файлах, структура которых может в значительной степени различаться.
Затем данные согласуются, агрегируются и переносятся в хранилище данных. Хранилище данных - это специализированная база данных, которая предназначена для хранения больших объемов ретроспективной информации о фактах и событиях различного рода. Выполнение данной задачи связано со следующими особенностями, влияющими на архитектуру хранилища данных:
загрузка информации, поступающей из большого количества несогласованных оперативных источников;
хранение и обеспечение оперативного доступа к большим объемам ретроспективной информации;
обеспечение оперативного выполнения неповторяющихся запросов, множества которых априорно не определено;
отсутствие необходимости частого внесения изменений в ранее загруженную информацию.
Хранилище данных является основным поставщиком информации для пользовательских моделей, используемых для анализа и поддержки принятия решений. Простейшим примером пользовательских моделей могут служить отчеты, формируемые на основе хранилищ данных. Часто используются и более сложные пользовательские модели, такие как Economic Value Added, Shareholder Value Added, Balanced Score Card и др.
Как правило, пользовательские модели получают информацию не из хранилища данных, а используют витрины данных, которые представляют собой некоторые проблемно-ориентированные выборки данных.
Таким образом, информация, прежде чем стать доступной управляющим, преобразуется в оперативных источниках, хранилище данных и витринах данных. Для обеспечения качества решений необходимо управлять качеством информации на каждом этапе обработки данных.
Управление качеством в основном представлено на уровне оперативных источников и пользовательских моделей. Качество данных на уровне хранилища, как правило, обеспечивается процессами согласования и агрегации и отвечает критериям качества пользовательских моделей.
В научной литературе (в частности, в работах Jarke М., Thalhammer Т., Vassiliadis Р. и др.) доказано, что для управления качеством информационной инфраструктуры необходима концептуальная модель предприятия, в соответствии с которой формируется физическая структура хранилища данных. Однако, по-прежнему, она, как правило, не получает обобщенного концептуального описания и остается набором разобщенных структур данных, создаваемых, исходя из потребностей пользовательских моделей. Основной причиной этого является трудность практической реализации подобных моделей.
Настоящее исследование посвящено созданию практически реализуемой технологии применения балансового метода для организации физической структуры хранилищ данных, использующихся для сбора информации о финансово-хозяйственной деятельности предприятий.
В современных условиях хозяйствования, отвечая на динамически изменяющийся спрос, необходимо постоянно преобразовывать организационные структуры предприятий и корректировать пользовательские модели, используемые для поддержки принятия решений. Это приводит к необходимости внесения изменений и в информационную инфраструктуру. В этих условиях процесс адаптации информационной инфраструктуры к постоянно изменяющемуся контексту функционирования должен сопровождаться не только контролем качества данных оперативных источников и пользовательских моделей, но и всего процесса преобразования данных. Поэтому в современных условиях вопросы построения концептуальных моделей деятельности предприятия, способных в значительной мере обеспечить увеличение качества информации, используемой для поддержки принятия решений и, как следствие, возрастание эффективности управления, приобретают особую актуальность.
Целью исследования является реализация информационной модели финансово-хозяйственной деятельности на основе балансового метода в хранилищах данных.
Объектом исследования являются хранилища данных о финансово-хозяйственной деятельности.
Предметом исследования является применение балансового метода описания финансово-хозяйственной деятельности предприятия для построения хранилищах данных.
Для достижения поставленной цели были определены следующие задачи исследования:
1. Анализ современных методов описания финансово-хозяйственной деятельности предприятия в хранилищах данных.
2. Создание информационной модели финансово-хозяйственной деятельности предприятия на основе балансового метода для построения хранилищ данных.
3. Разработка комплексной методики построения хранилища данных на основе модели финансово-хозяйственной деятельности предприятия.
4. Создание прикладной автоматизированной системы с использованием информационной технологии хранилищ данных на основе балансового метода.
Фундаментальной основой представляемого исследования послужили:
теория хранилищ данных (Hackney D., Inmon W.H., Kimball R., Mohania M., Schrefl M., Thalhammer Т. и др.);
общие методы управления качеством (Ю.П.Адлер, Аронов И.З., Ефремов B.C., Шпер В.Л, Akao Y, Taguti G и др.)
методы управления качеством данных в рамках информационной инфраструктуры и хранилищ данных (Дружинин Г.В., Литвинов В.А., English L. и др.). Особенно здесь выделяются работы, выполненные коллективом авторов в рамках проекта DWQ (в частности, Jarke М., Jeusfeld М.А., Quix С, Vassiliadis Р. и др.);
теория моделирования структур данных, прежде всего, фундаментальные основы реляционного и многомерного подходов к моделированию данных, методы моделирования "сущность-связь" (Bachman C.W., Codd Е. F., Date С, Chen Р. и др.);
концепции общих метамоделей и открытых систем (работы комитета Object Management Group, в частности, общая модель хранилищ данных -Common Warehouse Model).
Методы исследования. При решении поставленных задач в диссертационной работе использовались балансовый метод описания финансово-хозяйственной деятельности, системный подход к анализу проблем управления предприятием, теория множеств, теория графов, реляционный и многомерный подходы к проектированию баз данных, теория объектно-ориентированного проектирования, в частности, универсальный язык моделирования (UML).
Основные научные результаты, полученные лично соискателем, и их научная новизна заключается в следующем:
5. Проведен анализ современных методов описания финансово-хозяйственной деятельности предприятия, определены основные виды моделей, используемых при управлении предприятием, выявлены проблемы отражения деятельности предприятия в хранилищах данных. В частности, выявлены основные источники возникновения несоответствий в данных оперативных источников и рассмотрены основные пути их устранения.
6. Разработана комплексная технология применения балансового метода для построения модели финансово-хозяйственной деятельности предприятия. В частности, определены структурные элементы модели, рассмотрены способы выбора параметров модели и их многомерная структура, предложены способы группировки параметров.
3. Предложена технология многоуровневой трансформации данных при перегрузке данных из оперативных источников в хранилище данных с учетом согласования семантических структур описания хозяйственной деятельности на этих уровнях. Данная технология позволяет значительно снизить количество внутренних параметров, возникающих в процессе трансформации данных.
4. Предложена методика проектирования хранилищ данных в рамках балансового метода. Центральным звеном предлагаемой методики является формирование глоссария информационной структуры, с помощью которого устанавливается соответствие между семантическими структурами оперативных источников и хранилища данных.
5. Разработаны эскизные концептуальные модели для нескольких общих прикладных случаев. В частности, предложена эскизная модель торгово-закупочного цикла, включающего описание процесса регистрации и удовлетворения заявок клиентов и заказов товара у поставщиков.
6. Спроектирована и внедрена прикладная автоматизированная система Алеф с использованием балансового метода и технологии хранилищ данных.
Теоретическая значимость результатов исследования заключается в создании математической модели балансового метода применительно к построению концептуальной модели финансово-хозяйственной деятельности предприятия в хранилищах данных.
Практическая значимость результатов исследования заключается в повышении качества информации, используемой для принятия решений в области управления финансово-хозяйственной деятельностью предприятия. Результаты диссертационного исследования были применены при разработке прикладной автоматизированной информационной системы Алеф (Свидетельство о государственной регистрации N2002610485), которая использует балансовый метод и технологии хранилищ данных.
Личное участие автора в создание системы Алеф выразилось в разработке методического обеспечения и проектировании системы (в частности, в проектировании репозитория метаданных, подсистемы трансформации данных оперативных источников и др.).
Апробация работы. Теоретические и практические результаты исследования обсуждались на семинаре Клуба системных аналитиков (Москва, 1999 г.); на семинаре "Электронный бизнес" (Москва, 2001 г.); на конференции «Процессная ориентация деятельности. Формализованное описание и анализ бизнес-процессов. Методология моделирования бизнес-процессов ARIS. Информационная система предприятия Алеф» (Киров, 2001 г.); на 8-м семинаре Комитета по Логистике (Москва, 2001 г.); на 6-й научно-практической конференции "Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями" (Москва, 2002 г.).
Положения исследования нашли свое отражение в 12 печатных работах общим объемом 3.2 п.л.
Положения исследования, выносимые на защиту:
1. Технология применения балансового метода для построения модели финансово-хозяйственной деятельности предприятия.
2. Методика трансформации данных при перегрузке из оперативных источников в хранилище данных.
3. Комплексная методика проектирования хранилищ данных предприятия на основе балансового метода.
4. Эскизные концептуальные модели для нескольких общих прикладных случаев.
Объем и структура диссертации. Диссертационная работа состоит из введения, трех глав, заключения, списка используемой литературы и 5 приложений. Общий объем диссертационной работы составляет 146 страниц текста, 9 таблиц и 29 иллюстраций. Список используемой литературы включает 94 названия.
качеством информации Подходы к управлению
Качество информационных систем Вопросам качества информационных систем в настоящее время уделяется все большее внимание. Проблема отставания индустрии качества данных, о которой говорится в [72], отчасти была ликвидирована и вопросы качества корпоративных информационных систем, как правильно отмечается в [26], в настоящее время становятся частью систем качества предприятий.
В литературе встречается большое количество различных определений качества информации, где критерием качества выступают внешние свойства информационной системы. Например, "качество информации - это совокупность свойств информации, обуславливающих ее способность удовлетворять определенные потребности ее потребителей" [56]. Другое определение приводится в [76]: "качество данных отражает корректность и полноту данных".
На качество информации влияет множество факторов: согласованность семантических структур, описывающих объекты хозяйственной деятельности в различных подсистемах; наличие надежных протоколов обмена информации между приложениями; согласуемые представления реальных процессов в подсистемах; адекватность представления информации в оперативном уровне на этапе ввода информации в систему; адекватная интерпретация информации при передаче между подсистемами ИИ; надежность технических средств и прочие. Особую сложность представляет собой проблема управления изменениями ИИ при условии сохранения высокого уровня качества информации.
Кроме того, структура свойств информации с точки зрения пользователей во многом зависит от тех задач, которые пользователь решает в организации. Персонал, принимающий решения, интересует качество хранимой информации, ее актуальность и доступность. Для администраторов системы важна документируемость ошибок, легкость в управлении данными. Проектировщиков интересуют факторы качества моделей различного уровня и управление их эволюцией. И, наконец, программистов интересует информация о физической реализации объектов и метаданные об их связи между собой.
Проблемы управления качеством информации в различных аспектах рассматривались в работах [15], [16], [24], [32] и других.
В частности, рассматривались применение концепции тотального управления качеством к информационным системам [54] и к данным1 [92], методы обеспечения надежности аппаратных платформ и выбор архитектуры программно-аппаратных комплексов, для обеспечения оптимальной надежности [21], [25], критерии выбора оборудования [10].
Однако, с одной стороны, о качестве данных в ИИ нельзя судить только с учетом индикаторов качества технической инфраструктуры. С другой же стороны, обобщенное мнение экспертов выражено в [74]: "Рассмотрение одного только программного обеспечения недостаточно. Необходимо исследовать контекст его применения в бизнесе для ответа на вопрос: "Существует ли необходимость инвестировать в более высокое качество?"... В конечном счете, программное обеспечение хорошо, если бизнес хорош."
Рассмотрение вопросов качества информационных систем не случайно начато с описания методов качества, применяемых в промышленности. Многие методы оценки и подходы к управлению качеством в области информационных технологий наследуются из производства, где накоплен уже значительный опыт. Примером тому может служить широкое применение метода QFD при разработке программного обеспечения [28].
Процедура управление качеством данных, вырабатываемых в ИИ, начинается с определения факторов качества и их взаимосвязи (см. метод QFD). Качество в информационных системах регулируется стандартами [12] и [67]. В [67] приводятся следующие характеристики качества информационных истем: функциональность, надежность, используемость, эффективность, адаптируемость, портируемость и т.д.
Однако, как справедливо указано в [74], модель качества, представленная в стандартах, и другие подобные модели страдают недостаточностью обоснования выбора именно тех критериев, которые в модели используются. Часто под сомнение ставится эффективность тех или иных харакетристик качества. Кроме того, в этих моделях недостаточно прозрачны связи между индикаторами2 и укрупненными характеристиками, приведенными в таблице 1. "В результате, - высказывает свое мнение автор, -модель непроверяема" [74]
В работе [28] также высказывается мнение, что большое количество индикаторов качества с непрозрачными связями между собой затрудняют процедуру управления качеством.
Крайне сложной областью является выбор релевантных соотношений допустимых значений индикаторов. В [91], например, указывается, что подчас не лучшее решение проблемы, достаточно хорошее ("less than perfect") решение является лучшим. Оценка того, насколько удовлетворительное решение можно предпочесть лучшему, определяется условиями использования элемента программного обеспечения. Здесь важны и объем тиража, и географическая распределенность тиража, и ответственность функции, исполняемой элементом программного обеспечения (ПО), и прочее.
Ларри Инглиш в [56] рассматривает три основных компонента качества информации: качество информационной архитектуры - определяет адаптивные свойства ИИ и, следовательно, стоимость внесения изменений; качество содержания информации - определяет достоверность, полноту и неизбыточность информации; качество представления информации - определяет доступность системы для выполнения запросов пользователей и эффективность используемых средств представления данных.
Согласование "бизнес-номенклатуры" моделей оперативных источников и модели предприятия
ИИ содержит элементы, обработка и хранение информации в которых ведется различными способами. На рисунке 3 в главе 1 ИИ представлена разделенной на три перспективы (вертикальное деление) и три уровня (горизонтальное деление). Нижний уровень отражает оперативную обработку информации. Средний - накопление информации для анализа и верхний -инструменты доставки информации до пользователя и выполнения анализа.
При этом режим обработки информации на каждом уровне имеет свою специфику. На нижнем уровне - поддержка оперативных бизнес-процессов, высокая скорость обработки и изменчивость данных. На среднем - большие объемы, согласование данных из оперативных источников и невозможность оптимизировать структуры хранения под конкретные запросы. На высшем уровне существует необходимость быстрой навигации по информационным массивам, оперативного построения сложных аналитических отчетов, выполнения запросов и процедур анализа данных. Поэтому существуют значительные различия в методах построения и формального описания концептуальных, логических и физических моделей информационных систем.
Для обеспечения качества информации, кроме согласования моментов отражения, которые были рассмотрены выше, необходимо еще согласовать и семантические структуры оперативных источников. Они во многом определяются задачами, которые решают соответствующие элементы ИИ и методиками их проектирования. Поэтому необходимо глубже рассмотреть проблемы и методы согласования оперативных источников и модели предприятия. Структурирование данных в оперативных источниках
К концу 90-х годов для решения задач, связанных с управлением данными были предложены различные подходы: сетевая модель или модель "структур данных" [45], реляционный подход [51], модель набора сущностей [52] и др.
Наибольшее практическое применение по сей день имеет реляционный подход. Научный фундамент этого направления, определившего развитие индустрии хранения и управления данными на многие годы, положил Эдгар Кодд в работах [51] и [52].
Рассмотрим подробнее эту модель данных. Пусть существует множество объектов реального мира Ue. Объекты реального мира могут быть сгруппированы в подмножества, называемые бизнес-доменами. В рамках системы понятий определенной предметной области они идентифицируются с помощью концептов. Таким образом, в рамках определенной предметной области создается система концептов, описывающая универсум реальных понятий, значимых для данной предметной области - Uc. Uc = {С,,С2,...С, ,,}, где С,-концепты предметной области, а і = Цис\.
Для указания на определенный концепт пользователи прибегают к помощи терминов, совокупность которых U и составляет язык, с помощью которых пользователю естественно ссылаться на объекты того или иного бизнес домена.
U ={Тх,Тг,...Т,,}, где U - совокупность терминов предметной области, а i = l,\U \. В рамках реляционного подхода концепты на логическом уровне представляются в виде отношений.
Пусть дана совокупность множеств D„D2,..., Dn. "Отношение R, определенное на этих п множествах, есть множество упорядоченных п-ок или кортежей idx,d2,...,dn) таких, что dx Dx,d2 є D2,...,dn eDn. " [14]. Множества D,,D2,..., Dn называются доменами отношения R.
Элементы одного и того же домена могут участвовать в отношении несколько раз. Для идентификации использования домена в отношении вводится понятие атрибута отношения , определяющего уникальную функцию, выполняемую членом домена в отношении [14].
В [40] Петер Чен предложил подход "сущность-связь", который и по сей день является наиболее распространенным подходом к построению оперативных приложений. В [40] показано, что подход "сущность-связь" (Entity-Relationship) хорошо согласуется с реляционным подходом и даже расширяет его выразительные возможности. Он позволяет описывать достаточно сложную семантику реального мира в простой и понятной форме, посредством выделения сущностей и их связей.
В рамках этого подхода универсум концептов Uc описывается как совокупность сущностей предметной области - LP и их связей Ur. Ue = {Е\Е2,...Е и }, где Е - набор (коллекция) сущности предметной области, Заметим, что с точки зрения реляционного подхода сущности являются множеством упорядоченных п-ок /е і,е 2,...,е «Л, определенных на множествах
доменов, соответственно і, 2,..., «,, где i = l,Ue, а п{ - количество членов в кортеже і-ой сущности. Наборы связей R представляются как отношение между двумя сущностями (не обязательно различными) - то есть, чаще всего, как множество упорядоченных двоек rj =(ек,е \, где ек и е - экземпляры сущностей, соответственно, Ек и Е1, k = l,ue,l = l,uej, j = l,jur. Отметим, что в рамках подхода "сущность-связь" наборы связей представляются в виде m-ок, хотя при практической реализации чаще всего используются двойки. Ключ однозначно идентифицирует кортеж сущности. При этом предполагается его неизбыточность для идентификации кортежа. Кардинальность характеризует, сколько экземпляров сущностей ек и е1 связаны набором отношений R , состоящим из кортежей вида г = (ек ,е ). При физической реализации реляционного подхода сущности представляются в виде таблиц, а связи - в виде отношений между ними. Отношения устанавливаются с помощью ключей. В зависимости от кардинальности отношение может устанавливаться либо прямым указанием соответствия атрибутов и ключей (например, для кардинальности "один ко многим" (1:N)), либо с помощью вспомогательной таблицы (для кардинальности "многие ко многим" N:M).
Одна и та же сущность может входить в отношение более чем один раз. Для идентификации вхождения сущности в связь используется понятие роли. Роль сущности в связи определяет ту функцию, которую данная сущность выполняет в данной связи [40].
Одной из основных задач, которую решал Э.Кодд, являлось обеспечение независимости представления данных от приложений. Поэтому при использовании реляционного подхода должно удовлетворяться требование нормализации, которое заключается в том, что "значение каждого атрибута в отношении должно быть атомарным" [14]. Именно за счет выполнения требования нормализации в рамках реляционного подхода удается добиваться высокой производительности при обработке больших массивов данных с современных SQL-серверов.
"Кодд утверждает, что простота представления массива обеспечивает преимущество при обмене крупными порциями данных между системами, использующими различные представления данных "[55].
Кодд понимал, что "применение реляционной модели данных... дает возможность разработки универсального подъязыка данных, основанного на прикладном исчислении предикатов. Если набор отношений находится в нормальной форме, оказывается достаточным исчисления предикатов первого порядка" [52].
Введем понятие функциональной зависимости. Атрибут e t сущности Е! функционально зависит от атрибута е , этой же сущности, если каждое значение е к в каждый момент времени связано с одним значением е1,. При этом одно и то же значение атрибута может встречаться в различных кортежах несколько раз (то есть е1, может и не быть ключом).
Применение балансового метода для решения задач снабжения.
Рассмотрим применение балансового метода на примере построения торгово-закупочного цикла торговой компании.
Торговая компания осуществляет мелкооптовые поставки товаров клиентам, закупая их у поставщиков. При этом часть товаров поставляется со склада, а другая часть приобретается по просьбе клиентов в рамках договоров.
При поставке товаров практикуется двухфазная система резервирования - интегральный резерв и резерв на складе. Интегральный резерв предусматривает обеспечение потенциальной возможности поставить товар клиенту. Потенциальная возможность существует, если товар существует в достаточном количестве в некотором доступном пространстве, контролируемом компанией. В данном случае будем считать, что область, в которой товар может быть интегрально зарегистрирован, определяется всеми складами предприятия. Таким образом, при резервировании будет доступно количество товара, которое имеется на всех складах и свободно от резерва.
Резерв товара на складе применяется непосредственно перед выдачей товара клиенту. Этот вид резерва может быть наложен исключительно на остаток товара на конкретном складе. Это объясняется тем, что при отгрузке уже не будет возможности переместить товар с других складов.
Как уже говорилось выше, для балансирования показаний необходим единый измеритель, на основании которого производится сравнение результатов измерений. При построении модели производственных процессов используется материальный баланс предприятия. Все получаемые данные, используемые для расчета материального баланса в модели процесса, выражаются в единицах массы.
При разработке модели процедур в рамках торгово-закупочного цикла нам необходимо контролировать баланс для каждой единицы ассортимента. Поэтому единицы, в которых будет контролироваться баланс, зависят от способа измерения данной единицы ассортимента - штуки, килограммы, литры.
Пусть торгово-закупочный цикл включает следующие этапы:
1. Регистрация заявки покупателя. На этом этапе оформляется заявка клиента. Здесь существуют различные схемы выполнения сделок. Определяется, надо ли закупать товар для данного клиента или может быть осуществлена поставка со склада. Определяется финансовая схема операции.
2. Подготовка заказа поставщику. На этом этапе, руководствуясь правилами поддержания минимального остатка товара на складе и анализируя заявки покупателей, вырабатывается требования по поставке товаров, которые размещаются в виде заказов у поставщиков.
3. Поступление товара на склад. Поставщики обеспечивают выполнение заказов и поступление товара на склад. Товары, приобретенные не для конкретного клиента, поступают на склад и пополняют свободный остаток. Товары, которые приобретались для конкретного клиента, поступают на склад и автоматически резервируются как интегральный резерв.
4. Резервирование товара на складе. При подготовке отгрузки товара с конкретного склада товар, который должен быть отгружен по конкретному заказу, выводится из интегрального резерва и резервируется на данном складе.
На практике процедура выглядит гораздо сложнее. В данном примере предположим, что товар не имеет аналогов и в процессе товарооборота не случается пересортицы, когда один товар может быть, по ошибке или сознательно, заменен на другой товар. Кроме того, будем считать, что товар не подлежит сборке-разборке, что все склады доступны одинаково для формирования интегрального резерва. Существует много других упрощений, принятых в рамках данного рассмотрения. Это сделано для того, чтобы иметь возможность сосредоточиться на принципиальных моментах проектирования модели процесса в рамках субмодели товарооборота.
Прежде всего, выберем измеритель и определим структуру параметров субмодели товарооборота, для которых будем формироваться баланс, то есть выбираться такие связанные параметры, изменения совокупности которых в любой момент времени будет равно 0.
В данной субмодели измерителем будет являться количество единиц стандартных упаковок каждого артикула товара. Иными словами, баланс будет контролироваться для каждого артикула и измеряться в стандартных упаковках.
Параметры торгово-закупочного цикла Ниже подробно рассмотрены параметры с описанием их роли в данной субмодели. Параметр С1- "Планируемый Спрос" С помощью данного регистра формируются заявки на поставку, которые определяются отделом маркетинга, исходя из планируемого спроса.
Кредитовый оборот этого регистра показывает объем поставок, который необходимо обеспечить, чтобы удовлетворить потребительский спрос.
Дебетовый оборот этого регистра показывает фактический спрос, то есть тот спрос, который был удовлетворен поставкой товаров со склада.
Остаток (дебетовый оборот минус кредитовый оборот) этого счета показывает отклонение фактической картины спроса от прогноза. Поэтому с помощью этого параметра достаточно удобно прогнозировать спрос и анализировать отклонения фактической картины от плановой Параметр С2- "Заявки на Поставку "
Параметр заявки на поставку предназначен для организации внутренней деятельности компании, в частности, отдела закупок.
Заявки на закупку могут поступать от отдела маркетинга или от клиентов, для которых не оказалось необходимого товара на складе.
В случае, если заявка на закупку поступает от отдела маркетинга она отражается по дебету этого параметра. Но двойная запись требует, чтобы какой-либо иной параметр был также включен в операцию. В данном случае этим параметром будет являться параметр "Планируемый спрос", поскольку именно планируемый спрос заставил отдел маркетинга заказать данный товар.
В случае, если заявка поступила от клиента, параметр "Заявки на Поставку" увеличивается за счет уменьшения параметра "Неудовлетворенные Заявки".
Таким образом, дебетовый оборот этого параметра показывает суммарное количество поступивших заявок на поставку товара. Инициатора заявок - клиенты или отдел маркетинга - можно определить, исходя из уменьшаемого параметра.
Кредитовый оборот параметра "Заявки на поставку" показывает количество размещенных заявок в виде заказов различным поставщикам.
Данный параметр позволяет судить об эффективности закупочной деятельности в компании. Остаток счета в каждый момент времени показывает количество заявок, ожидающих размещения в заказах поставщикам. Параметр СЗ- "Заказы Поставщикам "
Параметр "Заказы Поставщикам" предназначен для отражения процесса исполнения заказов поставщиками. По дебету этого параметра отражаются размещенные заказы.
Кредитовый оборот показывает осуществление поставки товара на склад. В момент оприходования товара на склад товар записывается по кредиту параметра, уменьшая значение данного параметра. С помощью этого параметра можно также контролировать процесс поставки, если он предусматривает прохождение нескольких контрольных точек
LINK4 Построение балансовой модели предприятия с помощью программного продукта Система АЛЕФ LINK4 Краткая характеристика Системы Алеф
Система Алеф (СА) предназначена для создания автоматизированных информационных систем в рамках балансового метода. СА включает средства для автоматизации оперативного и аналитического уровней ИИ.
Система Алеф имеет следующие архитектурные уровни:Оперативная подсистема - обеспечивает уровень оперативных источников. В ней содержатся конструкторы, с помощью которых реализуются модули, обеспечивающие оперативную деятельность предприятия.Аналитическая подсистема - содержит конструкторы для построения хранилища данных и модели предприятия Интерпретатор - обеспечивает сбор, согласование и загрузку данных в аналитическую подсистему. Репозиторий метаданных - обеспечивает управление семантической структурой системы и согласование семантической структуры оперативных источников и модели предприятия.
На рисунке 26 представлена структура автоматизированной информационной системы. Оперативная подсистема Оперативная подсистема располагает широким арсеналом инструментальных средств. К ним относятся: Конструктор типов документов предназначен для создания новых типовдокументов, определения их форм и бизнес-логики. При определениинового типа документа в базе данных автоматически создается новая структура таблиц, обеспечивающая хранение содержимого документов данного типа. Привязка справочников к полям документа также производится с помощью визуальных средств.
Графический дизайнер форм позволяет разрабатывать экранные, печатные и списочные формы документов. Документ определенного типа может иметь несколько экранных форм, форм для печати и представления списков документов. Конструктор сценариев документооборота - предназначена для определения сложной бизнес-логики и технологии взаимодействия между документами, штатными процессами и внешними приложениями. Программный интерфейс и макросы. Для определения сложной бизнес-логики и технологии взаимодействия с внешними приложениями, обеспечения создания корпоративных информационных систем на уровне предметной области и обеспечения переносимости наработок на новые версии, оперативная подсистема включает мощный программный интерфейс. Система позволяет использовать такие механизмы интеграции с прикладными программами, как OLE, DDE, MAPI. Именно благодаря этим технологиям обеспечивается работа со стандартными офисными приложениями, такими как Microsoft Word, Microsoft Excel и др.Конструктор обмена XML сообщениями - предназначен, прежде всего, для обеспечения распределенной работы пользователей в режиме сеансового обмена сообщениями. В этом случае содержимое документа может быть преобразовано в вид сообщения XML.Аналитическая подсистема
Ядром аналитической подсистемы Системы Алеф является хранилище данных. Хранилище предназначено для создания банка аналитических данных корпорации и обеспечения работы учетного и аналитического контуров. При этом решаются следующие задачи: хранение больших объемов исторических данных; контроль соблюдения режима конфиденциальности; оперативная регистрация изменений с проверкой целостности баланса; оперативное предоставление информации в различных аналитических разрезах; контроль качества входящего потока данных (заполнение необходимых размерностей, значение размерностей по умолчанию); сопровождение хранилища данных во времени (слияние двойников, слияние периодов, изменение структуры параметров балансов);обеспечение взаимодействия с внешними источниками и потребителями информации, в том числе с промышленными системами OLAP.
В соответствии с балансовым методом создается структура хранилища данных, определяемая балансами и входящими в них многомерными параметрами (см. рисунок 27). В системе Алеф можно задать множество балансов и определить их параметрическую структуру.
Многомерные параметры в Системе Алеф связаны между собой правилом двойной записи, поэтому изменение состояния какого-либо одного параметра всегда сопровождается компенсирующим изменением состояния другого параметра.
Структура параметра модели предприятия в Системе Алеф двухчастная и может включать 48 независимых аналитических разрезов, причем разрезы могут определяться только с помощью понятий, зарегистрированных в семантической структуре. Интерпретатор
Конструктор операций хранилища предназначен для преобразования оперативных данных, загружаемых в аналитическую подсистему. Он призван решать следующие задачи: выполнение предварительной обработки и приведение данных к виду двойной записи и к структуре аналитики регистров; выполнение распределительных процедур (аллокирование);обеспечение переносимости настроек
