Інформаційні технології в організації бухгалтерського обліку та аудиту - Івахненков С.В. - Рівні програмування КСБО

Інформаційна технологія, що має досить тривалий період застосування, звичайно підлягає багаторазовій модифікації. Це пов'язано з необхідністю внесення змін і доповнень, викликаних змінами зовнішніх умов і вимог до бізнесу та бухгалтерського обліку. Умови ведення бухгалтерського обліку в Україні висувають специфічні вимоги до можливостей налагодження і допрограмування КСБО. Справа в тому, що імпортні бухгалтерські програми, на відміну від вітчизняних, розраховані на роботу в умовах стабільного фінансового і податкового законодавства. Саме тому для створення КСБО в Україні доцільно використовувати тільки українські та адаптовані російські програмні продукти.

Найкраще дозволяють налагоджувати КСБО і відповідають принципу гнучкості програми, побудовані за трирівневою архітектурою (рис. 4.4). Причому кожен рівень можуть створювати і налагоджувати різні фірми та групи спеціалістів із застосуванням різних мов програмування.

Рис. 4.4. Трирівнева архітектура КСБО

Є дві основні переваги використання такої структури КСБО. По-перше, це спрощена розробка та налагодження програм. Концептуально розробник в одному рівні має спрощене завдання, оскільки він може не вивчати деталей роботи розташованого нижче шару. По-друге, це підвищена безпека і захист. Конкретний розробник одного рівня не може контролювати розміщений нижче рівень. Отже, така структура може підвищити безпеку І секретність КСБО.

Великою проблемою у створенні КСБО є також брак стандартів для вбудованих мов програмування в бухгалтерських програмах. Наприклад, для розуміння програми, створеної в системі "1С: Бухгалтерия", необхідно вивчити мову програмування цієї системи, перевести програму на іншу мову програмування, наприклад "Инфософт" і тільки потім вручну переписати програму у іншій системі. Цікаву концепцію "візуального проектування", яка може значно пом'якшити цю проблему, пропонують розробники програми "Тектон" [43]. Традиційний підхід передбачає обов'язкову участь програмістів у створенні та налагодженні облікових завдань на конкретному АРМ, в якому також беруть участь користувач і бізнес-аналітик (рис. 4.5).

Рис. 4.5. Замкнуте коло процесу розробки АРМ

Для супроводження традиційних АРМ необхідно або мати на підприємстві штат програмістів (що коштує недешево), або звертатися з кожним запитанням до фірми-розробника. Концепція візуального проектування передбачає створення спеціалізованого інструменту для реалізації рішень, які пропонують кінцеві користувачі, й орієнтованого не на програмістів, а на бізнес-аналітиків. В основі концепції лежать такі принципи:

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

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

• користувач змінює або створює шаблони, процедури, документи та звіти, а за структуру бази даних відповідає програмний засіб;

• система має бути забезпечена простим інтерфейсом користувача, що забезпечує мінімально необхідні можливості. Однак у міру вивчення системи перед користувачем мають відкриватися все більші можливості.

Приступаючи до автоматизації конкретної прикладної галузі, бізнес-аналітик отримує завдання від кінцевого користувача. Застосовуючи "Тектон" як інструмент, він створює набір інструментів, звітів, шаблонів та процедур, а також виконує інші необхідні дії, формуючи віртуальний АРМ. Іншими словами, бізнес-аналітик налагоджує "Тектон" під конкретну прикладну галузь, створюючи в процесі такого налагодження інструмент для кінцевого користувача. Суттєвим є те, що в процесі такого налагодження не потрібно залучати професійних програмістів. Практично всю роботу може зробити бізнес-аналітик з використанням готових об'єктів, які заклали програмісти в систему "Тектон". Безумовно, в разі необхідності бізнес-аналітик може замовляти додаткові компоненти, звертаючись до програмістів або до сторонніх розробників. Унаслідок цього цикл розробки інформаційної системи для автоматизації додаткової діяльності суттєво спрощується (рис. 4.6).

Рис. 4.6. Цикл розробки при використанні концепції "Тектон"

Фактично вся взаємодія тут відбувається між кінцевим користувачем і бізнес-аналітиком. Вони не програмісти, але володіють прикладною галуззю. Розробку додаткової інформаційної системи веде бізнес-аналітик у термінах прикладної галузі без залучення традиційних мов програмування. Що ж до взаємодії бізнес-аналітиків з програмістами, то вона обмежується замовленням нових компонентів для системи. Створення таких компонентів не потребує детального ознайомлення з прикладною ділянкою роботи.