Рис. 1.8 Классификация исходящих документов

Рис. 1.9 Классификация внутренних документов

Результатом проведения предпроектного обследования и анализа всех документов, фигурирующих в системе диетпитания является таблица документов.

Рис. 1.10 Общая картина документооборота

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

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

.6 Математическая модель оптимального питания в санатории «Дубрава»

В качестве объекта моделирования рассмотрим подразделение «Врач-диетолог» системы «Оптимальное питание», как самое важное звено, определяющее принципы работы будущей системы.

Рассмотрим подробно, как функционирует это подразделение, чтобы смоделировать его математическую модель, а затем произвести ее оптимизацию.

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

Для наглядного представления механизма формирования диеты, с учетом необходимых веществ, запишем это в следующем математическом виде:

Пусть у врача-диетолога имеется m различных продуктов F₁,…, F_m. Из них он должен составить диету. Требуется, чтобы диета имела определенное количество питательных веществ, пусть их n: N₁,…, N_n.

Предположим, что каждому человеку в год необходимо С₁ единиц N₁, C₂ - N₂,…, C_n - N_n. Обозначим через a_ijколичествоj-го вещества, содержащегося в i-м продукте. Предположим, что врач выбрал диету, согласно которой в год каждый должен потреблять не менее y₁единиц продукта F_1, y₂ - F_2, …, y_m - F_m

Рассмотрим питательное вещество N₁. Так как в единице продукта F₁ содержится a₁₁вещества N_1, тогда в y₁единице продукта содержится a_11*y₁вещества N₁. Для F_mвy_mединице содержится a_m1*y_mвещества N_1.Во всей диете общее количество N₁:. Аналогично для остальных веществ.

 (1)

Диета, для которой выполняется выражение (1), называется допустимой диетой. Выполнение данного условия позволяет сформировать оптимальную диету.

Для приготовления какого-либо блюда из диеты используется определенный набор продуктов. Набор продуктов {П} для приготовления блюда Б_j является набором атрибутов этого блюда.

Можно записать:

Б₁= {П₁^1, П₃¹, П₂₅¹, П_е^1,…};

Б₂= {П₁², П₂²,… П₁₀², П_к²,…};

:

:

Б_j= {П₇^j, П₁₃^j, П₁₅^j},

где П_i^j - i-й продукт, используемый для приготовляемого j-го блюда

(i-вид продукта).

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

Отношения между блюдами, имеющимися в ассортименте, и продуктами, находящимися на складе и идущими на приготовление блюд, можно представить в виде двудольного графа, позволяющий наглядно представить модель взаимодействия блюд и продуктов (рис. 1.11).

Рис. 1.11 Общий вид двудольного графа связи блюд и продуктов

Множество вершин {Б_j} на графе отражает множество блюд, а множество вершин {П_i} - множество продуктов. Дуги отражают связь каждого блюда с продуктами, используемыми для его приготовления. Каждая дуга содержит вес брутто В_ji - вес i-го продукта, необходимый для приготовления одной порции j-го блюда.

Таким образом, путем инициализации одной из вершин Бj можно получить для блюда Бj список продуктов, необходимых для приготовления этого блюда, а также вес каждого продукта для приготовления одной порции. Эти данные необходимы для расчета количества сырья (по каждому продукту), которое кухня должна запросить со склада для приготовления блюд (с учетом необходимого числа порций по каждому из блюд). Аналогично можно выразить соответствие блюд Б_j и диет Д_iс помощью двудольного графа на рис. 1.12.

Рис. 1.12 Двудольный граф соответствия блюд и диет

На рис. 1.12. k_ij - калорийность j-го блюда вi-ой диете.

Для полного представления механизма формирования блюд, согласно выбранной диете, построим модель, использую метод БАС, позволяющий производить анализ, выбор, упорядочивание и оптимизацию модели, если потребуется.

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

Для всех приемов пищи существуют следующие категории блюд:

Q₁^r - закуски (салаты и др.);

Q₂^r - первое блюдо (супы);

Q₃^r - второе блюдо (мясное или рыбное блюдо с гарниром);

Q₄^r - третье блюдо (напитки);

Q₅^r - десерт (сладости или хлебобулочные изделия).

Следовательно, один прием пищи в общем случае может содержать все эти категории блюд:

Q^r = {Q₁^r, Q₂^r, Q₃^r, Q₄^r, Q₅^r}

или

Q^r = {Q_i^r},

где i = 1, 2,…, 5.

Для каждой из категорий существует свой набор блюд:

Q₁^r = (Б₁₁^r, Б₁₂^r,…, Б_1j^r,…, Б_1m^r);₂^r = (Б₂₁^r,…, Б_2j^r,…, Б_2l^r);

Q₃^r = (Б₃₁^r,…, Б_3j^r,…, Б_3k^r);

Q₄^r = (Б₄₁^r,…, Б_4j^r,…, Б_4h^r);₅^r = (Б₅₁^r,…, Б_5j^r,…, Б_5g^r).

При этом одно и то же блюдо может принадлежать к разным категориям.

На основе этих данных можно сформировать блочно-альтернативную сеть для завтрака (см. рис. 1.13.). Набор категорий блюд завтрака включает:

Q^З = (Q₁^3,Q₄³, Q₅^З).

Рис. 1.13 БАС завтрака

Сочетание различных блюд {Б_ij^З} образует маршрут М_e^З на сети завтрака. Маршрут выбирается целенаправленно, в соответствии с определенной диетой, т.е. с учетом блюд, разрешенных для данной диеты Д_k.

На сети получаем множество маршрутов М_k^З = {M_ke^З}, где

k - номер диеты,

k = 1,…, D, где D - количество диет;

е =1,…, L^З, где L^З - количество маршрутов по данным D диетам для завтрака;

М_ke^З = (Б_1j^З, Б_4j^З, Б_5j^З),

где индекс j - номер блюда в списке блюд определенной категории.

В общем случае маршрут выбора блюд на весь день для клиента с определенной диетой Д_k можно записать в виде:

М_kе = {М_ke^З, М_ke^О, М_ke^П, М_ke^У},

где k - номер диеты,

e - номер маршрута.

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

Д_k = {М_k1,…, М_ke,…, М_kL}.

Следовательно, для завтрака определенная диета Д_k будет иметь вид: Д_k^З = {М_k1^З,…, М_ke^З,…, М_kL^З}, k = 1, 2, …, D.

Каждый из маршрутов М_ke³ характеризуется калорийностью, содержанием белков, жиров, углеводов, а также витаминов и минеральных веществ:

М_ke³ = М_ke³ (К_ke³, БЛ_ke³, Ж_ke³, У_ke³, В_ke³, МВ_ke³),

k=1,…, D,

е =1,…, L.

Аналогичным образом может быть представлена БАС для обеда Q^О (см. рис. 1.14)

Q^О = {Q_i^О}, i =1,…, 5;

Q_i^О = (Б_i1^О, Б_i2^О,… Б_ij^О,… Б_iN^О).

Маршруты на БАС для обеда определяются путем выбора по одной альтернативной вершине для каждой категории блюд с учетом диеты:

Д_к^О = (М_k1^О, М_k2^О,…, M_kS ^О)

М_k^О = {M_k1^О}, k =1,…, N;

M_ks^О = (Б_1j^О, Б_2j^О, Б_3j^О, Б_4j^О)

М_ks^О = М_ks^О (К_ks^О, БЛ_ks^О, Ж_ks^О, У_ks^О, В_ks^О, МВ_ks^О);

k =1,…, N; s =1,…, S.

Рис. 1.14 Блочно-альтернативная сеть обеда

Блочно-альтернативная сеть полдника (см. рис. 1.15.) состоит из двух элементарных блоков:

Q^П={Q₁^П, Q₄^П}.

Рис. 1.15 Блочно-альтернативная сеть полдника

Q_i^П = (Б_i1^П, Б_i2^П,…, Б_iN^П);

М_k^П = {М_kp^П}, k = 1,…, D, p = 1,…, P;

М_kp^П = (Б_1j^П, Б_2j^П);

Д_к^П = (М_k1^П, М_k2^П,… М_kp^П);

М_kp^П = М_kp^П (К_kp^П, БЛ_kp^П, Ж_kp^П, У_kp^П, В_kp^П, МВ_kp^П).

Аналогично, можно представить БАС ужина (см. рис. 1.16.).

Q^У ={Q₁^У, Q₃^У, Q₄^У, Q₅^У};

Q_i^У =(Б_i1^У, Б_i2^У,…, Б_iN^У);

М_k^у ={М_ky^у}, k = 1,…, D, y = 1,…, Y;

М_kp^у =(Б_1j^у, Б_2j^у);

Д_к^у = (М_k1^у, М_k2^у,…, М_ky^у);

М_ky^у = М_kp^у (К_ky^у, БЛ_ky^у, Ж_ky^у, У_ky^у, В_ky^у, МВ_ky^у).

Рис. 1.16Блочно-альтернативнаясеть ужина

Выбор блюд на день методом БАС

Последовательно соединив все БАС завтрака, обеда, полдника и ужина, получим полную БАС одного дня; она представлена на рис. 1.17.

Рис. 1.17. Полная БАС блюд на один день

Как уже говорилось выше, определенная диета представляет собой множество всех маршрутов выбора блюд:

Д_k= {M_kе},

где k - номер диеты, k = 1,…, D;

e - номер маршрута, e = 1,…, L.

А каждый маршрут включает в себя множество маршрутов выбора блюд каждого приема пищи:

М_kе = {М_ke^З, М_ke^О, М_ke^П, М_ke^У}.

Множество всех маршрутов на БАС представлено на рис. 1.18.

Рис. 1.18. Незамкнутая БАС маршрутов выбора блюд

2.      Подготовка к проектированию

.1 Оптимизация математической модели

Рассмотрим объект оптимизации, то есть систему «Оптимальное питание», как объект управления с входными и выходными параметрами Х и У: ={}.

Рассмотрим входные вектора объекта:

= (номер клиента, фамилия, имя, отчество клиента, дата рождения клиента, заболевание клиента) - картаклиента.

=(номер диеты, название диеты, энергетическая ценность диеты, белки диеты, жиры диеты, углеводы диеты, витамин А, витамин В₁, витамин С, минерал Са, минерал Fe, минералKa) - содержание диет.

=(номер блюда, название блюда, рецепт блюда) - список блюд.

=(номер продукта, название продукта, энергетическая ценность продукта, белки продукта, жиры продукта, углеводы продукта, витамин А, витамин В₁, витамин С, минерал Са, минерал Fe, минералKa) - содержание продуктов.

 = (номер диеты, номер стола диеты) - соответствие столов диетам.

= (номер диеты, номер приема пищи, прием пищи) - соответствие приемов пищи диетам.

= (номер приема пищи, номер категории, категория) - соответствие категорий приемам пищи.

= (номер блюда, номер категории) - соответствие блюд категориям.

 = (диета, заболевания) - соответствие заболеваний диетам.

На выходе системы будут:

-рекомендуемая диета клиента;

-содержание блюд;

- подборка альтернативного блюда;

- подборка альтернативного продукта;

 - рацион питания клиентов;

 - количество каждого блюда;

 - количество пациентов каждой диеты.

Наглядно оптимизация системы «Оптимальное питание» будет выглядеть следующим образом (рис. 2.1).

Рис. 2.1 Модель оптимизации системы «Оптимальное питание»

Более подробно систему «Оптимальное питание» можно представить следующим образом (рис. 2.2).

Рис. 2.2 Оптимизация «Оптимальное питание» с информационными элементами

Где Е₁, Е₂, …, Е₇, Е₈ - информационные элементы объекта оптимизации.

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

Оптимизация составления оптимальной диеты

Пусть у врача-диетолога имеется n различных продуктов F₁, F₂,…, F_n, из которых надо составить диету с учетом их питательности. Пусть для нормального питания человеку необходимо m веществ N₁, N₂, …, N_m. Предположим, что за месяц каждому человеку необходимо g₁ кг вещества N₁, g₂ кг вещества N₂,…, g_m кг вещества N_m. Для составления диеты необходимо знать содержание питательных веществ в каждом продукте. Обозначим через a_ij количество i-го питательного вещества, содержащегося в одном килограмме j-го продукта. Всю эту информацию представим в виде, так называемой, матрицы питательности (табл. 2.1).

Таблица 2.1 Матрица питательности

Предположим, что диетолог уже выбрал диету, т.е. определил, что человек должен за месяц потреблять h₁ кг продукта F₁,…,h_n кг продукта F_n. Полное количество питательного вещества N₁ будет

По условию требуется, чтобы его, по крайней мере, хватило (1)

 (1)

Точно то же и для остальных веществ. В целом (2)

(2)

Эти условия определяют наличие минимума необходимых питательных веществ. Диета, для которой выполнены условия (2) - допустимая диета. Предположим, что из всех допустимых диет должна быть выбрана самая дешевая. Пусть p_i - цена 1 кг продукта F_i. Полная стоимость диеты, очевидно (3).

 (3)

Таким образом, мы пришли к задаче: найти неотрицательное решение h₁,…, h_n системы неравенств (2), минимизирующее выражение (3).

С чисто математической стороны решение данной задачи требует чтобы:

) все эти значения были неотрицательны;

) удовлетворяли системе линейных уравнений или линейных неравенств;

3) при этих значениях некоторая линейная функция имела бы минимум.

Таким образом, задача составления оптимальной диеты принимает следующийвид (4):

 (4)

и линейная функция (5)

 (5)

Требуется найти такое неотрицательное решение (6)

 (6)

системы (4), чтобы функция / принимала наименьшее значение.

Условия (8) называют ограничениями данной задачи, а функцию f - целевой функцией (или линейной формой).

Решение данной задачи помогает узнать необходимое потребление продуктов, содержащие в себе все необходимые питательные вещества, а также позволит оптимально составить диету при минимальных затратах.

Оптимизация подборки альтернативного меню

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

Рис. 2.3 Замкнутая БАС маршрутов выбора блюд

Преимущество использования замкнутой БАС с использованием алгоритма заключается в формирование вершинного маршрута, т.к. основная цель таких алгоритмов заключается в определении каждого элемента, в оценке согласованности с другими, а маршрут интерпретируется как модель результата решения (Рис. 2.4).

Рис. 2.4. Алгоритм составления меню

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

2.2 Анализ существующих информационных систем поддержки организации оптимального питания

На данный момент существует большое количество автоматизированных информационных систем поддержки организации оптимального питания. Но во всех системах присутствует один недостаток, это узконаправленная специфика, т.е. нет возможности проследить жизненный цикл услуги от назначения диеты врачом до непосредственного приема пищи проживающим. Выделим для примера две информационные системы «1C-АНАЛИТ: Диетпитание» и «ДИП Диетпитание 3.1». Информационная система «АНАЛИТ: Диетпитание» узко направлена, хотя и имеет некоторые функции, которых нет у информационной системы «ДИП Диетпитание 3.1». Хотя обе информационные системы реализована с помощью современных технических средств, в состав их не входят некоторые функции которые могли бы существенно облегчить работу персонала санатория «Дубрава».

Информационная система «1С-АНАЛИТ: Диетпитание»

Конфигурация «АНАЛИТ: Диетпитание» предназначена для автоматизации задачи обеспечения учреждения лечебным питанием. Данная задача затрагивает сразу несколько служб учреждений.

Диетслужба

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

Продслужба

Эта служба должна вести учет прихода, расхода, сроков годности продуктов на складе

Бухгалтерия.

Данная служба аккумулирует данные из первых двух служб. Формируется необходимая отчетность по движению продуктов, стоимости питания больных и т.д.

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

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

-       сезонные продукты (продукты, нормы отхода которых определяются сезоном)

-       производные продукты (продукты получаемые в ходе технологического процесса)

-       штучные продукты (проходящие по складу в штуках, а по диет-службе в граммах)

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

При поступлении продуктов на склад лечебного учреждения заполняется документ «Приходная накладная». При оформлении этого документа из справочника «Продукты» выбирается наименование продукта, указываются количество, цена за единицу и срок годности. Единица измерения (например, банка металл. 338 г.) также выбирается из соответствующего справочника. На основании цены за единицу продукта в дальнейшем будет рассчитана средне взвешенная стоимость питания пациентов по различным дням, пищеблокам и диетам.

Если необходимо сформировать меню на будущий период, а продукты еще не поступили (в основном это относится к скоропортящимся продуктам), то можно ввести документ «Планирование». Цены на продукты этот документ не содержит, так как они могут быть еще неизвестны. После поступления продуктов на основании документа «Планирование» формируется «Приходная накладная».

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

Ежедневную работу в программе по формированию меню на каждый день можно разделить на три этапа.

Первый этап: корректировка численности питающихся в учреждении. После внесения всех изменений печатается «Сводная ведомость»

Второй этап: создание одного экземпляра документа «Расчет меню». По умолчанию в данный документ загружается меню из указанного недельного меню, на требуемый день недели. В соответствии с наличием продуктов на складе его можно корректировать. Причем корректировка возможна как до начала, так и в процессе расчета. (Под расчетом понимается автоматический процесс резервирования продуктов на складе). При необходимости можно внести в меню индивидуальные столы. В процессе расчета может выясниться, что какого либо продукта не хватает для приготовления блюда в нужном количестве, в таком случае программа предложит перечень возможных замен. Если и возможных замен недостаточно, можно заменить блюдо целиком. При замене контролируется допустимость замены одного блюда на другое. На любом этапе предусмотрена возможность контроля количества белков, жиров, углеводов, калорийности питания больных по различным диетам учреждения, вплоть до каждого приема пищи. По окончании расчета автоматически формируются требования на получение продуктов. Отдельно для «весовых» продуктов, отдельно для продуктов, вес которых нельзя определить заранее (апельсины - приходуются в килограммах, назначаются по 1 штуке на человека). Кроме требований автоматически формируются другие необходимые печатные формы: «Меню», «Бракеражный журнал», «Меню-раскладка», «Раздаточная ведомость».

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

Выдача продуктов производится на основании требований, сформированных диет-службой. При выдаче, для отдельных категорий продуктов допускается округление отпускаемого количества. Кроме выдачи по требованиям допускается отпуск продуктов по расходной накладной. Это может быть выдача молока «за вредность», отпуск соли на процедуры и т.д. При изменении численности питающихся можно оформить возврат / дополучение продуктов со склада. Соответствующие документы формируются автоматически (по желанию ответственных работников).

Все отчеты в данной конфигурации можно условно разделить на две части:

-       используемые в повседневной деятельности;

-       необходимые для составления бухгалтерской отчетности.

К первой группе относятся: «Остатки продуктов на складе», «Сроки годности», «Соответствие нормам лечебного питания» и т.д.

Ко второй группе можно отнести «Сводная оборотная ведомость по продуктам», «Развернутая оборотная ведомость по продуктам», «Стоимость питания» и т.д.

Кроме этого предусмотрена печать всех справочных материалов, заведенных в систему.

Информационная система «ДИП Диетпитание 3.1»

Программный комплекс Диетпитание разработан «Научно-производственным центром «ДИП» совместно со специалистами Института Питания РАМН и предназначен для автоматизации диетслужб больниц, медицинских институтов и центров, а также других оздоровительных учреждений. Эксплуатация комплекса соответствует технологии, утвержденной Приказом Минздрава №330 от 05.08.03.

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

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

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

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

Карточки-раскладки блюд

Карточки-раскладки блюд хранятся в справочнике «Блюда». В них представлена информация о выходе готового блюда и полуфабриката, о содержании белков, жиров, углеводов и калорийности готового блюда, технология его приготовления и другие данные. При формировании карточки-раскладки врач-диетолог выбирает из справочника «Продукты питания» необходимые ингредиенты и добавляет их в карточку. Стоимость блюд рассчитывается программой автоматически, исходя из цен на продукты и их количества. Карточка-раскладка имеет стандартную печатную форму.

Меню, Заказы и Требование

Для ввода в систему новых меню по каждой диете на определенный день недели, а также для редактирования ранее созданных меню в конфигурации предназначен документ «Формирование меню». Информация о блюдах при заполнении этого документа выбирается из справочника «Блюда». В программе предусмотрено, что каждый прием пищи (1-й завтрак, 2-й завтрак и т.д.) может состоять максимум из семи блюд (Закуска, Первое блюдо и т.д.).

Работа с документом начинается с выбора диетического стола и дня недели. Если для выбранных параметров в системе уже существует ранее введенный документ, то он автоматически откроется и его можно отредактировать. В процессе работы с документом «Формирование меню» в любой момент, например, после добавления очередного блюда можно проконтролировать текущее содержание белков, жиров, углеводов и количество калорий, а также состав продуктов и затраты на питание больного. Программа позволяет присвоить меню статус «эталонного», то есть используемого в дальнейшем для конкретных дня недели и диеты «по умолчанию».

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

После того, как сформированы все заказы на текущий день, вводится документ «Требование на продукты», который может быть двух видов. Заполнение этого документа всеми текущими заказами выбранного вида производится автоматически. Документ «Требование на продукты» имеет печатную форму. Если после ввода «Требования» поступят новые заказы, то в этом случае составляется новое «Требование», и в него автоматически попадет информация только из тех заказов, по которым ранее «Требование» созданы не были. Документ «Требование на продукты» при проведении автоматически, в зависимости от выбранного вида («Выдача продуктов» или «Возврат продуктов») формирует соответствующие проводки.

Для удобства работы с документами по диетическому питанию в программном комплексе предусмотрены журналы документов. Журналы «Заказы блюд» и «Меню» применяются для просмотра, редактирования и удаления документов соответствующего вида. Со всеми без исключения документами диетической службы можно работать, используя журнал «Диетпитание».

Программный комплекс «Диетпитание» позволяет формировать различные отчеты по диетпитанию. Это «Раздаточная ведомость (отделения)» и «Раздаточная ведомость (кухня)», «Сводный порционник», «Раздаточная карточка» и другие. Возможна также печать журналов.

Сравнительный анализ рассмотренных информационных систем

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

Формирование структуры модели принятия решения в методе анализа иерархий достаточно трудоемкий процесс. Однако в итоге удается получить детальное представление о том, как именно взаимодействуют факторы, влияющие на приоритеты альтернативных решений, и сами решения. Как именно формируются рейтинги возможных решений и рейтинги, отражающие важность факторов. Процедуры расчетов рейтингов в методе анализа иерархий достаточно просты (он не похож на «черный ящик»), что выгодно отличает данный метод от других методов принятия решений.

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

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

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

Таблица2.2 - Сравнительный анализ 1C-АНАЛИТ: Диетпитание, ДИП Диетпитание 3.1, Разработанная ИС

В таблице 2.2 перечислены функции, которыми должна обладать система для организации диетпитания.

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

Таблица 2.3 - Относительные веса критериев

Заполнив таблицу2.3, сначала определяю оценки компонент собственного вектора, которые получаются как произведение относительных весов критерия по горизонтали, возведенного в степень 1/5 (где 5 - количество критериев).

Например, рассчитаю оценку собственного вектора для критерия «Формирование меню на каждый день»:

(1*1/4*1/3*1/3*1/5)^1/5 = 0,232179

Аналогично определяю остальные критерии.

Для того же критерия «Формирование меню на каждый день» вычисляю нормализованные оценки вектора приоритета, разделив оценки собственного вектора на их сумму, равную 6,415485.

,232179 / 6, 544518 = 0, 04117Так же рассчитываю остальные критерии.

Получив сумму по каждому критерию в столбцах, вычисляю значение матрицы, умножая нормализованные оценки вектора приоритета на эту сумму. Например, для критерия «Формирование меню на каждый день»:

*0, 04117 = 0, 82141

Просуммировав, получаем максимальноесобственное значение матрицы (λ max).

λ max = 5,67467

Таблица 2.4 - Сравнение ИС

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что наибольшее значение я придаю критерию «Простота освоения и использования», наименьшее - «Формирование меню на каждый день».

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

ИС = (λ _max - n)/(n - 1),

где λmax - максимальное собственное значение матрицы (λ _max≥ n),размерность матрицы

ИС = (6,42823 - 5)/ (5-1) = 0,058187

Разделив ИС на число, соответствующее случайной согласованности матрицы шестого порядка, равного 1,12, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе надо проверить свои суждения.

ОС = 0,058187 / 1,12 = 5,2% < 10%, т.е. пересматривать свои суждения нет нужды.

Построю матрицу сравнений, сравнивая попарно альтернативу из строки с альтернативой из столбца по отношению к критерию «Формирование меню на каждый день». Никакие другие критерии при этом не учитываю. Значения из шкалы относительной важности вписываю в ячейки, образованные пересечением соответствующей строки и столбца. Диагональ этой матрицы заполняю значением «1», а ячейки, лежащие ниже диагонали - обратными значениями.

Таблица 2.5 - Сравнительные оценки систем по критерию «Формирование меню на каждый день»

Относительная согласованность матрицы равна 3,91%, т.е. <10%.

Таблица 2.6 - Сравнительные оценки систем по критерию «Учет сроков годности продуктов»

Относительная согласованность матрицы равна 7,41%, т.е. <10%.

Таблица 2.7 - Сравнительные оценки систем по критерию «Формирование отчета меню-требование.»

Относительная согласованность матрицы равна 8,08%, т.е. <10%.

Таблица 2.8 - Сравнительные оценки систем по критерию «Наличие отчетных форм по движению продуктов»

Относительная согласованность матрицы равна 8,11%, т.е. <10%.

Таблица 2.9 - Сравнительные оценки систем по критерию «Просмотр назначений диет проживающим».

Относительная согласованность матрицы равна 7,31%, т.е. <10%.

Результаты оценок по всем критериям представлены в таблице 2.10.

Для каждой из альтернатив заполняю столбцы критериев значениями локальных векторов приоритета.

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

Таблица 2.10 - Сравнительные оценки систем по всем критериям

Выбранной альтернативой считается альтернатива с максимальным значением глобального приоритета. Сравнение систем приведено в таблице 2.11.

Таблица 2.11 - Сравнение ИС

Анализ данных, приведенных в таблице 2.11 показывает, что следует остановить свой выбор на разработанной информационной системе.

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

2.3 Функциональные требования к информационной системе поддержки организации оптимального питания в санатории «Дубрава»

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

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

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

Ведение бракеражного журнала - функция, позволяет проводить контроль приготовленных блюд по следующим параметрам:

-       соблюдение технологических процессов,

-       санитарное состояние,

-       отметка о разрешении к выдаче блюд.

Просмотр остатков на складе - функция обеспечивает своевременное планирование расхода продуктов, объемов закупок, является крайне удобной функцией при формировании меню-требования.

Ведение журнала осмотров сотрудников - функция позволяет вносить данные по осмотрам сотрудников и формировать соответствующие отчетные формы.

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

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

Автоматизированная обработка меню-требования - функция предназначена для автоматического формирования приходно-расходных документов при подтверждении выдачи продуктов в соответствии с меню-требованием.

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

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

Главными требованиями к работе разрабатываемой системы являются:

1.       Контроль и учет продуктов, необходимых для питания;

2.      Учет затрат на обеспечение питания;

.        Автоматическое формирование меню - требования на каждый день;

.        Ведения журнала осмотра сотрудников пищеблока на гнойничковые заболевания;

.        Контроль процесса закладки продуктов в котел;

.        Контроль доброкачественности готовых блюд.

7.       Автоматическое формирование отчетов по расходованию продуктов.

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

В системе выделены следующие функциональные единицы:

·   Модуль «Меню-требование»;

·        Модуль «Журналы по диетпитанию».

Модуль «Меню-требование»

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

Функциональность модуля:

·      Отображение данных об имеющихся продуктах на складе;

·        Отображение сведений о количестве проживающих, находящихся на довольствии по диетам;

·        Формирование меню-требования с учетом норм расхода, предоставляемых бухгалтерией;

·        Автоматическое обновление меню-требования (его пересчет) при изменении числа проживающих более чем на 3 человека;

·        Поступление меню-требования к завскладом для выдачи продуктов;

·        Возможность печати меню-требования для его последующего поступления к шеф-повару для закладки продуктов в котел;

·        Поступление меню-требования в бухгалтерию для расчета стоимости питания.

В модуле необходимо предусмотреть возможность поддержки следующих справочников:

·      Нормы по питанию);

·        Справочник замены блюд.

Печатный модуль «Журналы по диетпитанию»

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

Модуль содержит следующие журналы:

·   «Журнал осмотра на гнойничковые заболевания»;

·        «Журнал закладки продуктов»;

·        «Журнал С-витаминизации»;

·        «Бракеражный журнал готовой пищи»;

·        «Журнал бракеража скоропортящихся продуктов»;

·        «Журнал отбракованных продуктов на склад»;

·        «Журнал контроля доброкачественности продуктов, поступивших на пищеблок»;

·        «Производственный журнал».

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

2.4 Построение функциональной модели информационной системы поддержки оптимального питания в санатории «Дубрава»

При формировании функциональной модели информационной системы ключевым моментом является декомпозиция функции «Формирование меню-требования». Рассмотрим декомпозицию блока «Формирование меню-требования». Все поступления продуктов в учреждения и их расход фиксируются в системе. Совместный учет расходов и приходов дает данные об остатках, на основании которых формируется перечень необходимых продуктов. При возникновении необходимости замены продуктов диетсестра использует справочник замены продуктов, который формирует автоматически список замены на основании первичного перечня продуктов, что является важным фактором экономии времени. Для наиболее качественного и эффективного составления меню диетсестра имеет возможность получать информации обо всех назначенных проживающим диетам за счет интеграции с другими подсистемами. Автоматизированная система на основании выбранных продуктов и количестве проживающих формирует меню-требование, готовое к передачи в бухгалтерию и шеф-повару.

Рис. 2.5 Модель формирования меню-требования

3. Проектирование информационной системы поддержки организации оптимального питания в санатории «Дубрава»

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

Исходя из поставленных задач, в системе будет задействовано шестнадцать сущностей:

·   «Блюдо меню-требования»,

·        «Витаминизация меню»,

·        «Готовое блюдо»,

·        «Диета для блюда»,

·        «Замена продукта»

·        «Контроль продуктов меню»,

·        «Меню-требование»,

·   «Норма денежных средств»,

·   «Норма продукта»,

·        «Отбраковка»,

·        «С-витаминизация»,

·        «Сотрудник на осмотр»,

·        «Сотрудник, принявший закладку продуктов»,

·        «Тип приема пищи»,

·        «Диета»,

·        «Продукт».

Теперь нам предстоит описать атрибуты сущностей.

Сущность «Блюдо меню-требования» (TDish) описывается следующими атрибутами:

·        fk_menu - ссылка на меню-требование,

·        fk_dish - ссылка на блюдо,

·        fn_brutto - весбрутто,

·        fk_meal_type - ссылка на тип приема пищи,

·        fc_san_status - санитарное состояние пищеблока.

Сущность «Витаминизация меню» (TVitamin) описывается следующими атрибутами:

·   fk_vitamin _id - ключевое поле (уникальный идентификатор),

·        fn_vitamin - содержание аскорбиновой кислоты,

·        fn_count - число витаминизированных порций,

·        fn_one_tabl_count - содержание аскорбиновой кислоты в таблетке,

·        fk_menu - ссылка на меню,

·        fk_sotr - лицо, ответственное за витаминизацию.

Сущность «Готовое блюдо» (TReadyDish) описывается следующими атрибутами:

·   fk_ready_dish_id - ключевое поле (уникальный идентификатор),

·        fc_name - наименование блюда,

·        fc_code - кодблюда,

·        fn_brutto - вес_брутто,

·        fn_netto - вес_нетто,

·        fc_tech - технологияприготовления,

·        fk_meal_type - ссылка на тип приема пищи,

·        fb_sotr - питание сотрудников,

·        fk_change - замена (наименование блюда, которое может послужить заменой для данного).

Сущность «Диета» (TDiet) описывается следующими атрибутами:

·   fk_diet_id - ключевое поле (уникальный идентификатор),

·        fb_type - тип (номерная или стандартная),

·        fс_description - описание.

Сущность «Диета для блюда» (TDishDiet) описывается следующими атрибутами:

·   fk_dish_diet_id - ключевое поле (уникальный идентификатор),

·        fk_dish - блюдо,

·        fk_diet - ссылка на диету.

Сущность «Замена продукта» (TProductChange) описывается следующими атрибутами:

·   fk_product_change_id - ключевое поле (уникальный идентификатор),

·        fn_old_prod - масса заменяющего продукта,

·        fn_new_prod - масса заменяемого продукта,

·        fk_old_product - продуктзаменяемый,

·        fk_new_product - продукт_заемняющий.

Сущность «Контроль продуктов меню» (TControl) описывается следующими атрибутами:

·   fk_control_id - ключевое поле (уникальный идентификатор),

·        fd_postavka - время поставки на пищеблок,

·        fk_product_link - ссылка на продукт,

·        fk_menu_link - ссылка на меню,

·        fn_count_breakf - кол-во продуктов для закладки,

·        fk_meal_type - ссылка на тип приема пищи,

·        fn_netto - масса_нетто,

·        fn_brutto - масса_брутто,

·        fn_not_food_wastes - массанепищевыхотходов,

·        fn_food_wastes - масса пищевых отходов,

·        fk_waste_reason - ссылка на причину отбраковки.

Сущность «Меню-требование» (TMenu) описывается следующими атрибутами:

·   fk_menu_id - ключевое поле (уникальный идентификатор),

·        fk_link_shablon - ссылка на шаблон,

·        fc_number - номер,

·        fb_shablon - принадлежность шаблонам,

·        fd_date - дата,

·        fk_money_norm_link - ссылка на норму денежных средств.

Сущность «Норма денежных средств» (TMoneyQuota) описывается следующими атрибутами:

·   fk_money_quota_id - ключевое поле (уникальный идентификатор),

·        fd_finish - дата окончания,

·        fd_start - дата начала,

·        fn_norm - кол-во денег на одного человека,

·        fb_budjet - бюджет(внебюджет),

·        fk_norma_link - сдедующая норма.

Сущность «Норма продукта» (TProductQuote) описывается следующими атрибутами:

·   fk_product_quote_id - ключевое поле (уникальный идентификатор),

·        fn_one_norm - норма на 1 человека,

·        fk_link_product - продукт.

Сущность «Отбраковка» (TScreening) описывается следующими атрибутами:

·   fk_screening_id - ключевое поле (уникальный идентификатор),

·        fc_reason - причина отбраковки.

Сущность «Сотрудник» (TSotr) описывается следующими атрибутами:

·   fk_sotr_id - ключевое поле (уникальный идентификатор),

·        fc_name - имя,

·        fc_surname - фамилия,

·        fc_patronimyc - отчество,

·        fb_sex - пол,

·        fd_date_born - дата рождения,

·        fn_code - уникальный личный номер.

Сущность «Продукт для блюда» (TDishProduct) описывается следующими атрибутами:

·   fk_dish_product_id - ключевое поле (уникальный идентификатор),

·        fk_link_product - продукт,

·        fk_link_sem_product - продукт-полуфабрикат,

·        fn_netto - нетто,

·        fk_link_dish - блюдо,

·        fn_brutto - брутто.

Сущность «Продукт-ингредиент полуфабриката» (TSemifinishedProductPart) описывается следующими атрибутами:

·   fk_semifinished_product_part_id - ключевое поле (уникальный идентификатор),

·        fk_link_semprod - ссылка на продукт-полуфабрикат,

·        fk_link_prod - продукт-ингредиент,

·        fn_count - количество.

Сущность «Продукт-полуфабрикат» (TSemifinishedProduct) описывается следующими атрибутами:

·   fk_semifinished_product_id - ключевое поле (уникальный идентификатор),

·        fn_weight - вес,

·        fc_name - наименование.

Сущность «Сотрудник на осмотр» (TSotrCheck) описывается следующими атрибутами:

·   fk_sort_check_id - ключевое поле (уникальный идентификатор),

·        fk_sotr_link - ссылка на сотрудника,

·        fk_menu_link - ссылка на меню,

·        fb_angina - отметка об отсутствии ангины,

·        fc_note - примечание,

·        fb_sex - пол,

·        fd_date_born - дата рождения.

Сущность «Сотрудник, принявший закладку продуктов» (TCheckProductSotr) описывается следующими атрибутами:

·   fk_check_product_sotr_id - ключевое поле (уникальный идентификатор),

·        fk_menu_link - cсылка на меню,

·        fk_sotr_link - cсылка на сотрудника.

Сущность «Тип приема пищи» (TMeals) описывается следующими атрибутами:

·   fk_meals_id - ключевое поле (уникальный идентификатор),

·        fс_name - наименование.

Сущность «Продукт» (TProducts) описывается следующими атрибутами:

·   fk_product_id - ключевое поле (уникальный идентификатор),

·        fс_name - наименование,

·        fn_protein - белки,

·        fn_fat - жиры,

·        fn_carbon - углеводы.

Рис. 3.1 Логическая модель данных

Рис. 3.2 Физическая модель данных

Заключение

В дипломном проекте проведена разработка информационной системы поддержки организации оптимального питания в санатории «Дубрава».

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

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

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

-   проведено обследование работы подразделения обеспечения питания;

-       произведен анализ существующих аналогов;

-       сформулированы требования к разрабатываемой подсистеме и задачи, которые должна выполнять система;

-       сформулирована характеристика объекта автоматизации и построена структурная и функциональная модель организации питания.

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

Расчет технико-экономических показателей разработки системы сравнение с аналогом доказали эффективность разработки.

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