К текущей ликвидности

3. К текущей ликвидности

А1+А2+А3 3853+16725+27873

КТЛн.г = ---------------- = ------------------------------ = 1,00 (11)

П1+П2 13573+35046

А1+А2+А3 31438+57820+213539

КТЛк.г = ---------------- = ----------------------------- = 1,03 (12)

П1+П2 221315+73176

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

К критической ликвидности, так же не соответствует нормативному значению, причем в 1996 году наблюдается снижение на 0,12.[1]

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

Коэффициент текущей ликвидности рассчитывается по формуле:

А1+А2+А3

К1 = ----------------------- (13)

П1+П2

Откуда на начало периода:

К1 = 1,00

а на конец:

К1 = 1,03

Коэффициент обеспеченности собственными средствами рассчитывается по формуле:

П4-А4

К2 = --------------------  (14)

А1+А2+А3

В нашем примере на начало периода это составит:

11

К2 = ------------------------------- = 0,0002.

3853+16725+27873

а на конец:

14911-6442

К2 = ---------------------------------- = 0,0280.

31438+57820+213539

В зависимости от полученных конкретных значений К1 и К2 анализ и оценка структуры баланса развиваются по двум направлениям:

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

К3а = ( К1ф + 6 / Т * ( К1ф - К1н ) ) / 2 (15),

где: К1к - фактическое значение коэффициента текущей ликвидности

(К1) в конце отчетного периода;

К1н - фактическое значение коэффициента текущей ликвидности

(К1) начале отчетного периода;

6 - период восстановления платежеспособности в месяцах;

Т - отчетный период в месяцах (12 месяцев);

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

Для нашего примера определять значения К3б нет необходимости, поскольку значения К1 и К2 меньше предельных значений (соответственно 1,00 и 1,03).

Если К1 и К2 меньше соответствующих предельных значений, следует рассчитать коэффициент восстановления платежеспособности за 6 месяцев:

К1к + 6 / Т * (К1к - К1н)

К3а = ----------------------------------- (16),

К1норм

где: 6 - период восстановления платежеспособности;

Т - отчетный период (12 месяцев);

К1норм - нормативное значение коэффициента текущей ликвидности (К1), равное 2.

Если коэффициент утраты платежеспособности К3а примет значение больше 1, то у кооператива имеется реальная возможность восстановить свою платежеспособность. В нашем примере К1к = 1,03: отсюда:

1,03+6/12*(1,03-1,00)

К3а = ------------------------------- = 0,5225

2

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

2. ОБЪЕКТИВНО-ОРИЕНТИРОВАННЫЙ ПОДХОД ПРИ ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ

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

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

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

Системы автоматизации деятельности средних и крупных компаний имеют не только модули для работы с финансовой информацией, но и программы автоматизации делопроизводства, управления проектами, распределения товаров по складам и др. Среди наиболее распространенных и активно продвигаемых систем на казахстанском рынке можно назвать системы Scala, Platinum и программы R/3 немецкого концерна SAP-лидера на сегодняшний день в области автоматизации деятельности предприятия.

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

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

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

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

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

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

Методика построения крупных программных систем в качестве одного из первых шагов предусматривает предварительное определение структуры рассматриваемой области с точки зрения взаимодействия составляющих ее частей. [5]

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

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

Поэтому основной задачей при создании подобных систем является задача определения базовых объектов и механизмов взаимодействия между ними.

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

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

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

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

В качестве связующего компонента при построении систем предлагается использовать технологию OLE 2 фирмы Microsoft, так как:

- OLE - встроенное средство операционных систем Windows 95 и многоплатформной Windows NT;

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

- в виде распределенного OLE в сети реализована возможность хранения объектов на различных компьютерах;

- совместимость с OLE является требованием спецификации CORBA.

Хранение информации.

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

Гибридные БД. Они выступают в качестве связующего компонента между объектно-ориентированными и реляционными БД, заполняя возникшее пространство между двумя технологиями. В гибридных схемах используются несколько подходов (от промежуточного слоя ПО до чисто реляционного подхода с трансляцией запросов, поступающих от приложений в язык SQL).

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

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

Перед системой, которая должна охватывать все аспекты деятельности кооператива, ставится задача получения и обработки информации, поступающей из различных источников и имеющей различные форматы представления. Унифицированная передача данных позволяет не только обмениваться информацией между объектами OLE, но и передавать информацию в приложения, не поддерживающие эту технологию, но умеющие работать с буфером обмена данными Clipboard. Такая технология избавляет разработчика от необходимости знания того, как и откуда поступают данные. Основными методами являются Query Get Data, Get Data, Set Data и Enum Format Etc. Методы Query Get Data и Enum Format Etc служат соответственно для определения того, поддерживает ли объект запрашиваемый формат данных, и для получения списка всех поддерживаемых объектом форматов.

Если множества поддерживаемых форматов данных у объектов не пересекаются, то имеется возможность использования объектов-трансляторов. Технически при этом происходит опрос реестра операционной системы в целях поиска объектов, поддерживающих необходимые типы данных, и организуется последовательный процесс вызова методов Get Data и Set Data. Используя этот механизм, объект 1 получает возможность хранить данные в формате объекта 2, т.е. в их первоначальном виде, а обрабатывать в своем собственном формате.

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

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

Для поддержки обновления данных целесообразно использовать метод D Advise интерфейса I Data Object объекта-сервера в совокупности с интерфейсом l Advise Sink объекта-клиента. В зависимости от необходимости существует возможность установления одного из трех типов связи между объектами: «холодной»;«теплой»;«горячей».

«Холодная» связь. Такие связи могут использоваться для обмена информацией по заранее определенным схемам. Использование только методов Get Data при обмене информацией между объектами может служить примером этого типа связи.

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

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

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

После определения характера взаимодействия между объектами системы встает вопрос о необходимости описания с их помощью конкретной структуры кооператива. Как отмечалось, такая операция является завершающей и может выполняться на этапе внедрения системы в кооперативе. Очевидно, что данная операция должна выполняться сравнительно легко и позволять гибко модифицировать связи между компонентами системы. В этом случае можно использовать такие средства, предоставляемые OLE, как OLE Automation и автоматные контроллеры. Если до этого момента рассматривался обмен данными между объектами, то с использованием Automation объекты получают возможность управлять действиями друг друга. Обмен информацией происходит через интерфейс IDispatch посредством вызова метода Invoke для активизации действий, выполняемых данным объектом. В системе управления кооперативом имеет смысл определить, например, расдача корма животным, ленточным способом, посредством компьютера, который будет инициатором создания документов для отражения в документообороте движения материальных ценностей. Список поддерживаемых объектом методов возвращается путем вызова метода Get Type lnfo интерфейса I Dispatch аналогично тому, как запрашивается список поддерживаемых форматов через интерфейс I Data Object. Благодаря этому существует возможность добавления на этапе функционирования системы новых объектов, отражающих изменения в реальной жизни и их интеграции в систему. Необходимо заметить, что это не требует изменений в уже существующих объектах.