Гужва В.М. Інформаційні системи і технології на підприємствах

Подождите немного. Документ загружается.

354

• Додатки до балансу.

• Звіти про податки.

3. Розрахунки економічних показників.

• Аналітичний баланс.

• Розрахунок рентабельності.

• Розрахунок стійкості.

• Розрахунок оборотності.

• Розрахунок ліквідності.

Кількість і склад форм вихідної бухгалтерської звітності, їх

оформлення і методики розрахунку можуть змінюватися залежно

від таких чинників:

• чинного законодавства;

• вимог вищестоящих організацій і податкових органів у ме-

жах діючого законодавства;

• специфіки діяльності та структури підприємств, визначаль-

них особливостей обліку.

Усі перелічені чинники зумовлюють необхідність постійної

доробки форм вихідної бухгалтерської звітності.

У бухгалтерському контурі «Галактики» ця проблема ви-

рішена наданням користувачеві можливості легко скоригувати

будь-яку існуючу або створити власну звітну форму. Ця можли-

вість ґрунтується на використанні вмонтованої в систему мови

проектування звітів. Даною мовою виконані всі вихідні форми

бухгалтерської звітності й документи з розрахунку економічних

показників. (рис. 9.12).

Технологія створення нової звітної форми є надто простою і

складається з таких кроків:

• формі, що створюється, треба привласнити найменування,

яке надалі з’являтиметься в переліку обраних для друку звітних

форм;

• за допомогою вбудованого текстового редактора створюєть-

ся шаблон звіту, що включає «шапку», «боковик», стовпчики, пі-

дписи;

• на кожній сторінці шаблона в місцях, де повинні знаходити-

ся розрахункові дані, проставляються найменування розрахунко-

вих полів, а нижче окремими рядками записуються самі формули

розрахунку.

Як змінні в розрахункових формулах використовуються

проводки по рахунках, обороти і сальдо по рахунку. Структу-

ра найменувань змінних строго визначена і має такий вигляд

(Рис. 9.12. Квадратними дужками виділені необов’язкові ком-

поненти):

355

Вид змінної > [< період розрахунку >] <вид обороту >

< основний рахунок > \ < кореспондуючий рахунок

П — проводки

О — обороти

С — сальдо

Г — рік

К — квартал

П — попередній місяць

ММ — номер місяця

Д — дебет

К — кредит

<номер рахунка>

[<номер субрахунка>

<КАО>]

<номер рахунка>

[<номер субрахунка>

<КАО>]

Приклад:

СКК 02_01 — сальдо на початок поточного кварталу по

кредиту рахунка 02, субрахунка 01

ПГД 20\70_01 — сума оборотів з початку року по проводках

типу «Дебет 20 - кредит 70/01»

Рис. 9.12. Мова проектування звітів

Розрахункова формула може включати перевірку відносин

значень змінних (рівно, нерівно, більше, менше тощо), а також ло-

гічні операції («так», «або», «ні»). Мова проектування звітів про-

ста в освоєнні, наближена до звичної для бухгалтера термінології

і дозволяє користувачеві оперативно адаптувати свої звіти до по-

точних змін зовнішніх вимог.

9.2.5.5. Багатоплановість рахунків

бухгалтерського обліку

За допомогою модуля «Консолідація» в «Галактиці» реалі-

зується можливість паралельного обліку в декількох планах ра-

хунків бухгалтерського обліку, тобто багатопланових рахунків.

Один план рахунків може, наприклад, відповідно українським

стандартам, інші — російським чи стандартам GААР. Кількість

планів рахунків програмою не обмежується. Перемикання між

ними провадиться натисненням певної комбінації клавіш.

Користувач може самостійно визначати найменування планів

рахунків, вводити будь-які номери рахунків (близько 19 алфавіт-

но-цифрових символів) та назви їх. В усіх планах можна вводити

субрахунки, коди аналітичного обліку, вести контроль допусти-

мої кореспонденції. Типові господарські операції можуть бути

356

настроєні таким чином, щоб одночасно формувати проводки по

всіх існуючих планах рахунків, причому в кожному з них — у

необхідній кореспонденції і з розрахунками сум оборотів.

9.2.5.6. Консолідована звітність корпорації

За допомогою вже згаданого модуля «Консолідація» забезпе-

чується можливість ведення консолідованої (спільної) бази даних

корпорації і отримання консолідованої звітності. Під корпораці-

єю в цьому разі треба розуміти об’єднання декількох юридичних

осіб. Усі вони ведуть роздільний бухгалтерський облік по одно-

му і тому самому набору планів рахунків. Один із учасників кор-

порації вважається головною фірмою, інші — філіями. Ця від-

мінність не відбивається на способі подання даних або роботі з

ними. Для простоти можна вважати головну фірму також філією.

Кожна філія, в свою чергу, може мати безліч офісів.

Загальна (консолідована) база даних створюється різними

способами:

• Під час ведення обліку по філіях на одному комп’ютері або

в єдиній обчислювальній мережі. Додаткові програмні засоби не

потрібні.

• Під час передачі даних через електронну пошту, модем або

на дискетах. У цьому разі потрібне об’єднання їх за допомогою

програми міжофісного обміну даними Соrро.

У модулі «Консолідація» користувач має ряд можливостей:

• встановлювати потрібний йому план рахунків, вид консолі-

дованих звітів. Для кожного виду визначається набір філій, що

включаються;

• для обраного виду звіту визначати, які операції філій відби-

рати для роботи: тільки зовнішні, тільки внутрішні, всі (і зовніш-

ні, і внутрішні ).

Внутрішніми вважаються операції між учасниками корпорації,

зовнішніми — з контрагентами, що не входять у корпорацію.

При роботі з іншими модулями контуру бухгалтерського обліку

користувач має доступ до даних і може отримувати звіти по за-

даній філії корпорації і у встановленому плані рахунків.

Модуль «Консолідація» забезпечує отримання узагальнених

звітів про рух коштів корпорації, що відображається на рахунках

аналітичного обліку, і контроль сальдо на початок і кінець звіт-

ного місяця.

Мова проектування звітних форм забезпечує створення форм

загального балансу корпорації та інших видів звітів. Для доступу

357

до даних різних філій в іменах змінних передбачений спеціаль-

ний елемент, що включає код філії. Він повинен передувати ін-

шим елементам імені змінної, наприклад:

&1 = F0_СД51+F1_СД51.

Змінній &1 привласнюється значення суми сальдо по дебету

рахунка 51 головної фірми (філія з кодом «0») і філія з кодом «1»

на початок звітного періоду.

Отримання загальних балансів та інших форм звітності може

бути подане такою схемою (рис. 9.13).

Загальна база даних корпорації

Головна

фірма

Філіал

«Схід»

План

рахунків 1

План

рахунків 1

План

рахунків 1

План

рахунків 2

План

рахунків 2

План

рахунків 2

План

рахунків 3

План

рахунків 3

План

рахунків 3

Баланс

головної

фірми

у плані

рахунків 1

Баланс

«Заходу»

у плані

рахунків 1

Баланс

«Сходу»

у плані

рахунків 1

Загальний

баланс

План

рахунків 1

Загальний

баланс

План

рахунків 2

Загальний

баланс

План

рахунків 3

рахунків 2 рахунків 2

рахунків 2

рахунків 3 рахунків 3

рахунків 3

Філіал

«Захід»

Рис. 9.13. Схема отримання звітності

358

9.3. ІНФОРМАЦІЙНА СИСТЕМА УПРАВЛІННЯ

ПІДПРИЄМСТВОМ MIRACLE V

9.3.1. Базові принципи побудови

ІС Miracle V являє собою інтегровану інформаційну систему уп-

равління бізнесом, засновану на найновітніших технологіях та су-

часних методах. Ця інформаційна система здатна адаптуватися до

вимог та потреб компаній-користувачів. Для досягнення цього го-

ловна увага фокусувалася на бізнес-процесах. Маючи в своєму роз-

порядженні інформаційну систему, підприємство отримує інстру-

ментарій, який дозволяє йому постійно вдосконалювати процеси,

що відбуваються всередині нього, та оптимізувати їх з метою як-

найкращого використання можливостей середовища, що постійно

змінюється. Дотримання цих вимог неможливо забезпечити звичай-

ним адміністративним програмним рішенням, параметри якого мо-

жна настроювати лише до певної міри. Замість стандартного стати-

чного програмного забезпечення підприємство може впровадити

управлінську інформаційну систему, вільну від звичайних недолі-

ків.

Інформаційна система Miracle V була розроблена саме для за-

доволення таких вимог. Miracle V заснована на всеохопній

управлінській моделі. Пропонується декілька таких моделей за-

лежно від галузі, в якій працює компанія. Вони можуть бути лег-

ко і прозоро перебудовані відповідно до конкретних вимог дано-

го підприємства. Безболісна модифікація моделей можлива

завдяки інструментарію Miracle V, котрий включає: перемоде-

лювання чи опис нових процесів; зміну структур даних; вве-

дення нових функціональних залежностей, перебудову форм

та документів. Існує можливість спостереження за кожним про-

цесом чи сферою діяльності, їх аналізу та симуляції на основі на-

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

ються в графічному вигляді за допомогою компоненти Business

Process Modeller. Компонента Business Executer відкриває та здій-

снює запуск процесів без додаткових проміжних кроків.

Проілюструвати це допоможе приклад — опрацювання вхідного

рахунка-фактури у компанії «Байк Інк». У «Байк Інк» усі рахунки-

фактури проходять стадію початкового опрацювання (рис. 9.14). За-

лежно від зазначеного обсягу деякі рахунки-фактури мають бути

підтверджені. Інформаційна система повинна вказати для кожного

рахунка-фактури дату, до якої він має бути підтверджений, а також

359

відповідальну особу. Після підтвердження рахунки-фактури повин-

ні бути зареєстровані і направлені до оплати. Компоненти Business

Підпис

Передача до оплати

Сума < 1000. --Ј

Рахунок-

фактура

початковий

Введення

Визначення

критичної

дати

Попередня інформації

Передача

до оплати

Відмовлення

в підписі

Сума > = 1000. --Ј

Так

Ні

Рис. 9.14. Рахунки до оплати, вхідні рахунки-фактури

359

361

Process Executer відповідає за виконання процесу, розробленого у

Process Modeller. Коли певна особа виконала своє завдання в межах

процесу, наприклад «Введення рахунка-фактури», система автома-

тично генерує нове завдання для особи (або групи), відповідальної за

підтвердження. Так Miracle V передає завдання від особи до особи.

Ланкою комерційної діяльності (деякі зв’язки для спрощення

опущені) може бути, наприклад, ця діаграма (подібну до неї мож-

на розробити для будь-якого процесу).

Вказівка «V» у назві «Miracle V» підкреслює віртуальність ці-

єї інформаційної системи. Віртуальність означає, що кожне підп-

риємство (навіть таке, що, можливо, ще не існує) в усіх його ас-

пектах (процеси, дані, організація тощо) може бути змодельоване.

Такі змодельовані процеси можуть бути негайно виконані за допо-

могою виконавчої системи, вбудованої в Miracle V.

Придбання розробленого за звичайною схемою стандартного

програмного забезпечення подібне до придбання вже збудовано-

го будинку. Зміни, хоча й обмежені, можуть бути внесені завдяки

розширенню або реконструкції (окремі версії програмного забез-

печення). План будинку все-таки залишається незмінним та ста-

тичним, що накладає певні обмеження.

У Miracle V немає формального чи наперед заданого рішення.

З бібліотеки довідкових (референтних) моделей підприємство

обирає ту, що найкраще відповідає його вимогам. Довідкова мо-

дель у Miracle V — це повнофункціональна та внутрішньо узго-

джена інформаційна система. Там, де процеси, функції та структу-

ри не повністю відповідають потребам підприємства, вони можуть

бути змінені та модифіковані за допомогою інструментарію Mi-

racle V. Якщо продовжувати аналогію з будинками, підприємство

може обрати будинок-модель (довідкова модель-приклад) і адап-

тувати його до своїх потреб. За допомогою Miracle V, або, точні-

ше, її засобами для розробників, підприємство створює свою влас-

ну, таку, що повністю відповідає його потребам та вимогам,

інформаційну систему. Всі процеси моделюються графічно, подіб-

но до блок-схеми, і потім вводяться до системи. Структури даних

та зв’язки їх можуть за необхідності змінюватися. За допомогою

дизайнера форм їх можна змінювати та створювати наново. Ін-

струмент запитів дозволяє впроваджувати запити на будь-якій ста-

дії, протягом впровадження системи або пізніше.

Усі визначення та описи (процеси, форми, документи, струк-

тури даних тощо) інтерактивно взаємопов’язані. Вони функціо-

нують як правила роботи для інформаційної системи і детально

описуються у своїй власній базі даних, яка називається Repository

362

(сховище). Вони також можуть змінюватися чи розширюватися в

будь-який час. Структури Repository контролюють усю виконав-

чу систему Miracle V. Repository є «вихідним кодом» для системи.

У наш час успіх підприємства великою мірою залежить від його

здатності швидко реагувати на зміни. Звідси випливає, що бізнес-

процеси також повинні адаптуватися, аби відповідати новим умо-

вам. Перепроектування організацій та процесів вимагає наявності

інформаційних інструментів для підтримки виконання відповідних

завдань. Додатки Miracle V відповідають таким вимогам. Business

Process Modeller забезпечує підтримку управлінської діяльності, до-

зволяючи створювати нові процеси та адаптувати наявні. За допо-

могою симуляції наслідків втілення нових ідей різні варіанти можна

тестувати, перш ніж впроваджувати їх на підприємстві. Перепроек-

тування бізнес-процесів одержує добру підтримку завдяки такій

здатності їх симулювати. Все більш досконалі аналітичні засоби

можуть генерувати надійні результати лише тоді, коли вони постій-

но використовуються в буденній діяльності підприємства. Саме то-

му організація та інформаційна система мають працювати взаємо-

поєднано. Філософія Miracle V базується на цій ідеї, оскільки вико-

нуються лише процеси, необхідні в щоденній роботі підприємства.

Інформація про бізнес-завдання всередині конкретних відділів

чи в межах усього підприємства звичайно поширена серед невели-

кої групи людей. Відповідна документація або не існує, або є заста-

рілою. Неефективна проробка завдань може бути виявлена лише за

умови докладання величезних зусиль або не може бути виявлена

взагалі. За допомогою компоненти Miracle V Business Process

Modeler усі процеси відображаються графічно і одночасно здійсню-

ється прямий вплив на інформаційну систему. Це означає, що від-

повідна документація, згенерована Process Modeler, у будь-який

момент залишається актуальною. Оскільки процеси відомі інфор-

маційній системі, а вся відповідна інформація (про виконані завдан-

ня) реєструється, ефективність процесів може аналізуватися на ос-

нові бази поточних даних. Динамічна система підтримки користу-

вача також користується інформацією від Process Modeler. Вона

завжди показує користувачам, у якому процесі вони перебувають,

попередні та наступні завдання і відповідальних за них.

Коли впроваджується нова інформаційна система або модифі-

кується наявне рішення, менеджери, інженери з програмного за-

безпечення та користувачі можуть висловлювати різні думки та по-

гляди на стадії аналізу інформаційного проекту. Це може призвести

до непорозумінь та неузгоджень, які усвідомлюються на значно

більш пізній стадії, звичайно у фазі виробництва, що призводить до

363

конфліктів та зростання витрат. Інструмент графічного аналізу

Miracle V — Process Modeler — допомагає «спорудити мости» між

різними групами, дозволяючи їм краще розуміти одна одну.

Стандартне програмне забезпечення набуває дедалі більшого

поширення у сучасному бізнесі, а індивідуальне програмне за-

безпечення використовується лише у виняткових випадках. При-

кладні програми, які виробляються масово, коштують менше, во-

ни дозволяють використовувати досвід інших, а постійне вдос-

коналення програмного забезпечення гарантується. Все це добре,

але при цьому користувач отримує лише обмежені функціональні

можливості, процеси ж розроблені для загального використання,

а не для задоволення індивідуальних потреб. Окрім того, має іс-

нувати еволюційний взаємозв’язок між наявними процесами та їх

застосуванням. Miracle V розв’язує цю проблему, надаючи спе-

ціально розроблені рішення для конкретних галузей, які можуть

бути легко графічно адаптовані. Завдяки об’єктно-орієнтованому

підходу в Miracle V будь-які модифікації автоматично поширю-

ються на нові версії. Це означає, що не потрібно повторно прово-

дити зміни для наступних версій Miracle V. Завдяки такій струк-

турі Miracle V має переваги як у стандартному, так і в розроб-

леному на замовлення програмному забезпеченні.

9.3.2. Основні компоненти

інформаційної системи Miracle V

Опис компонентів Miracle V наведено нижче (рис. 9.15).

Процеси і відповідні їм

потоки даних

на

підприємстві визначені, вимоги до

інформаційної системи сформульовані

Process

modeler

Transaction

processer

Class

master

Прикладні додатки

Miracle V

Впроваджен-

ня офісних

додатків

Обмін

Електронна

пошта

Intranet

Internet

та ін.

Значення: Аналіз Додатки

Розробка та впровадження Зв’язок

Інформаційна платформа

архітектури клієнт/сервер

Repository

Executer (генерує вихідні

коди

для

додатків)

Рис. 9.15. Miracle V – компоненти