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

План

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

2. Вплив інформаційних систем на розвиток реінжинірингу бізнес-процесів

3. Вплив інформаційних систем на організаційну структуру компанії

 

 

Впровадження системи автоматизації управління, як і будь-яке серйозне перетворення в компанії, є складним процесом. Проте, деякі проблеми, що виникають під час впровадження системи, досить добре вивчені, формалізовані і мають ефективну методологію розв’язування. Завчасне вивчення цих проблем та підготовка до них значно полегшують процес впровадження і підвищують ефективність подальшого використання системи. Можливість враховувати під час автоматизації особливості конкретної компанії набуває все більшого значення і для розв’язування аналітичних задач, правильне розуміння яких дозволяє компанії зміцніти свої позиції на ринку.

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

Виділяються два основні підходи до проектування систем управління компанією та інформаційних систем їх підтримки, а саме: структурний і процесний.

Одним з можливих підходів, що базується на використанні організаційної структури, є проектування системи згідно виділених центрів відповідальності. Методика обліку витрат в цьому випадку описується через технології роботи центрів відповідальності, а їх взаємодія регламентується на рівні стратегічного обліку. Найбільш значущим недоліком структурного підходу є прив'язка до організаційної структури, схильної до зміни, тому доводиться часто вносити зміни в методологічний аспект інформаційної системи.

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

Процесний підхід підводить до необхідності переходу на, так званий, «стратегічний» варіант управління. Основними рисами такої реорганізації є:

·нарівні з широким делегуванням повноважень і відповідальності виконавців, керівництво компанії повинно мати чіткі стратегічні та тактичні цілі, в тому числі і в галузі автоматизації;

·працює ієрархічна структура управління - тобто розпорядження керівництва, безумовно, обов'язкові для виконавців з одночасним скороченням кількості рівнів прийняття рішення;

·автоматизація методики виконання бізнес-процесів;

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

Основними принципами управління проектом УІС виступають:

1.Принцип успіху. Без досягнення успішного продукту УІС накладні витрати на управління проектом не приносять користі. Було багато проектів, що були виконані «вчасно та у межах бюджету», але це не завжди спричиняло їх економічну доцільність.

2.Принцип зобов'язань. Взаємно прийняті зобов'язання між спонсором проекту і командою, що займається проектом, повинні існувати до того, як з'явиться життєздатний проект. Спонсор проекту - це знаюча людина, яка представляє остаточного власника продукту, і яка відповідає за забезпечення необхідними ресурсами. Взаємно прийняті зобов'язання - це ті зобов'язання, в яких погоджені цілі проекту на основі можливості продукту, якості, часу завершення (виготовлення) продукту й остаточна вартість.

3.Принцип альтернатив. Основні значення процесу управління проектом УІС: можливості продукту, якість, час виробництва продукту і вартість завершення - повинні бути взаємно погодженими. Основні значення масштабу, якості, часу і вартості взаємозалежні і нагадують рамку у формі чотирикутника.

4.Принцип єдиноначальності. Між спонсором і керівником проекту повинен існувати єдиний канал комунікації для передачі всіх рішень, що впливають на продукт проекту. Цей принцип необхідний для ефективного розподілу зобов'язань щодо проекту. Власник остаточного продукту, навіть якщо він представлений більш ніж однією особою, незважаючи ні на що, має право одного голосу. Також протягом усього періоду команда, що займається проектом, повинна мати одну відповідальну особу, керівника проекту, для роботи над ним. У такої людини повинні бути навички, досвід, відданість справі, повноваження і завзятість, необхідні для успішного здійснення проекту.

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

6.Принцип процесу. Для виконання зобов'язань проекту повинні існувати ефективні політики і процедури. Такі політики і процедури повинні передбачати, як мінімум, чіткі ролі й обов'язки, передачу прав і відповідальності, процеси з управління масштабом робіт, включаючи зміни, збереження якості, своєчасність виконання і контроль над витратами.

7.Принцип життєвого циклу. Процес успішного управління проектом складається з двох великих фаз: спочатку планування, потім виконання. Ці дві послідовні фази складають основу життєвого циклу кожного проекту і можуть бути розширені, щоб відповідати контрольним вимогам кожного проекту в будь-якій сфері. Життєвий цикл проекту, що характеризується «етапами», означає початок проекту, тобто «контрольну риску», яку він повинний перетнути, і кінець проекту.

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

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

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

Відмінною рисою інформаційно-аналітичних систем у процесі моделювання є використання методології IDEFО, яка відрізняється, по-перше, унікальною здатністю «запитувати» у процесі моделювання, а, по-друге, нерозривним зв'язком графічних засобів, методології та технології. З цього погляду IDEFО є, мабуть, єдиною, котра надає не тільки засіб відображення бізнес-процесів, але і методологію взаємодії «аналітик-фахівець», і, крім того, технологію створення проектів, що охоплює всі стадії «життєвого циклу» - від первинного аналізу до форми представлення остаточного проекту.

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

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

Типова структура ІАС включає технологічну і просторово-комунікаційну інфраструктури, логічну структуру баз даних, що використовувалися, і комплекси технічних засобів.

Основою концепції розробки ІАС є логічна інтеграція інформації, що складає предметні області користувачів, та її фізичний розподіл за територіально вилученими вузлами.

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

Як основні критерії ефективності використовуються мінімум та максимум сумарного часу виконання «робочого навантаження» різних класів користувачів.

Підвищення ефективності експлуатації, розроблених ІАС, обумовлює необхідність розробки і впровадження формалізованих моделей і методів реорганізації структур баз даних.

Метою проектування є створення ефективно функціонуючої УІС. В процесі проектування удосконалюються як організація основної діяльності економічного об'єкта (виробничої, господарської), так і організація управління.

Основоположні принципи проектування і створення УІС були сформульовані академіком В.М. Глушковим. До них відносяться принципи: системності, розвитку, сумісності, стандартизації і уніфікації, ефективності.

Принцип системності припускає розгляд об'єкта як єдиного цілого; виявлення зв'язків між структурними елементами, що забезпечують цілісність системи; встановлення напрямку виробничо-господарської діяльності системи і функції, що реалізовуються нею.

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

Принцип сумісності полягає в забезпеченні здатності взаємодії УІС різних видів і рівнів в процесі їх сумісного функціонування.

Принцип стандартизації і уніфікації означає застосування типових, уніфікованих і стандартизованих елементів функціонування УІС, що дозволяє скоротити витрати часу, праці і грошових коштів на її створення.

Принцип ефективності полягає в досягненні раціонального співвідношення між витратами на створення УІС і ефектом, що одержується під час її функціонування.

Етапами проектування є:

·формулювання і аналіз вимог до системи;

·концептуальне проектування;

·проектування реалізації;

·фізичне проектування.

Основною метою першого етапу є фіксація вимог до процесів обробки даних в системі з боку її користувачів. Аналіз вимог дозволяє погоджувати інформаційні потреби користувачів і забезпечити єдине розуміння змісту бази даних.

Концептуальне проектування дозволяє створити структуру бази даних, незалежну від конфігурації обчислювальної системи, СУБД і системного програмного забезпечення (названі компоненти вибираються після етапу концептуального проектування).

Проектування реалізації припускає проектування структури бази даних стосовно вибраної СУБД і проектування структури основних прикладних програм.

На етапі фізичного проектування відбувається визначення параметрів БД, пов'язаних із зберіганням даних в пам'яті ЕОМ, процедурами доступу до даних, а також відбувається налагодження прикладних програм. З цієї миті можливо заповнення БД реальними даними (актуалізація) і функціонування системи в робочому режимі.

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

Під модернізацією розуміють процес коректування проектних рішеньщодо окремих компонентів УІС.

Залежно від змісту початкової інформації для розробки структури бази даних розрізняють об'єктний і функціональний підходи щодо її проектування. Об'єктний підхід припускає опис об'єктів і зв'язків предметної області без урахування інформаційних потреб користувачів. При функціональному підході основним джерелом інформації про предметну область служать запити користувачів (завдання). Відмінність між двома підходами показана на рис.13.

Основними перевагами об'єктного підходу є хороша відповідність структури бази даних і предметної області, можливість реалізації великої кількості наперед не запланованих запитів до бази даних без модифікації її структури (ця властивість називається стійкістю структури БД), можливість оптимізації методів організації даних для бази даних в цілому.

Недоліком об'єктного підходу є необхідність аналізу великої кількості об'єктів і зв'язків в предметній області, що робить його досить трудомістким.

 

 

 

 

Рис. 13. Об'єктний і функціональний підходи до проектування УІС

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

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

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

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

Дотримання приведених принципів необхідне під час виконання робіт на всіх стадіях створення і функціонування УІС, тобто протягом всього їх життєвого циклу.

Життєвий цикл (ЖЦ) - період створення і використання УІС, починаючи з моменту виникнення необхідності в даній автоматизованій системі (технології) і закінчуючи моментом її повного виходу з вживання у користувачів.

Життєвий цикл УІС дозволяє виділити чотири основні стадії: передпроектну, проектну, впровадження і функціонування. Кожна стадія проектування ділиться на етапи.

Перша стадія включає два етапи: збір матеріалів для проектування та їх аналіз, формування документації. На першому етапі формуються вимоги, вивчається об'єкт проектування, розробляється і вибирається варіант концепції системи. На другому етапі забезпечується створення і затвердження техніко-економічного обґрунтування і технічного завданнящодо проектування системи.

Друга стадія також включає два етапи: перший передбачає пошук найбільш раціональних проектних рішень по всіх аспектах розробки, створення і опису всіх компонентів системи; результатом етапу є технічний проект; на другому етапі здійснюється розробка і доведення програм, коректування структур баз даних, створення документації на постачання, установку технічних засобів і інструкцій щодо їх експлуатації,

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

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

Четверта стадія називається стадією промислової експлуатації і передбачає повсякденне функціонування і супровід програмних засобів і всього проекту, оперативне обслуговування і адміністрування баз даних.

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

Порядок виконання етапів в ході розробки автоматизованих інформаційних систем і технологій, а також критерії переходу від етапу до етапу залежать від вибраної моделі ЖЦ. Найбільшого поширення набули три наступні моделі ЖЦ:

·каскадна модель, яка припускає перехід на наступний етап після повного закінчення робіт щодо попереднього етапу;

·поетапна модель з проміжним контролем або з циклами зворотного зв'язку між етапами;

·спіральна модель, яка робить упор на початкові етапи ЖЦ (аналіз вимог, проектування специфікацій, попереднє і детальне проектування). На цих етапах перевіряється і обґрунтовується реалізація технічних рішень шляхом створення прототипів. Кожен виток спіралі відповідає поетапній моделі створення фрагмента або версії автоматизованої ІС. На ньому уточнюються цілі і характеристики проекту, визначається його якість, плануються роботи наступного витка спіралі.

Найбільш перспективною є спіральна модель ЖЦ, що надає ряд переваг перед іншими моделями:

·можливістю накопичення і повторного використання проектних рішень, засобів проектування, моделей і прототипів автоматизованої ІС;

·орієнтацією на розвиток і модифікацію системи і технології в процесі їх проектування;

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

Під час проектування автоматизована інформаційна система розглядається в п'яти взаємозв'язаних аспектах:

·технічному - як апаратно-комунікаційний комплекс, що має конкретну конфігурацію для обробки і передачі інформації;

·програмно-математичному – як набір статистичних, математичних, інфологічних, алгоритмічних та інших машинно-орієнтованих моделей, а також комп'ютерних програм, що їх реалізовують;

·методичному – як сукупність засобів реалізації функцій управління по відношенню до економічного об'єкта - компанії, об'єднання, регіонального господарства;

·організаційному – як опис документообігу і регламенту діяльності апарату управління;

·післяопераційному – як сукупність технологічних, логічних і арифметичних операцій, що реалізовуються в автоматичному режимі.

Під час розробки автоматизованих інформаційних систем слід дотримуватися ряду вимог:

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

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

·охоплення основних етапів життєвого циклу управління (вироблення альтернатив ухвалення рішень, вибір найбільш раціонального варіанта управлінської стратегії, моніторинг і контроль виконання рішень);

·здібності до адаптації всієї системи (гнучке пристосування до змін ринкового середовища, можливість швидкого перемикання на різні режими використання апаратних і телекомунікаційних засобів);

·орієнтації на реалізацію єдиної інформаційно-логічної моделі об'єкта управління в поєднанні з необхідними процедурами обробки даних і виведення результатів;

·синхронізація процесів обробки і видачі інформації з процесами ухвалення рішень на всіх рівнях;

·використання безпаперового документообігу, природно-професійної мови для спілкування фахівця з ЕОМ, електронних підписів, машинних архівів і бібліотек, видаленого доступу до масивів даних;

·можливості обробки великих обсягів інформації в регламентному і довільному режимах, а також інтеграції даних відповідно до ієрархії управління;

·наявності експертної підтримки, обліку інформації, можливості отримання прогностичних даних.

В процесі розробки автоматизованих систем і технологій проектувальники стикаються з низкою взаємозв'язаних проблем:

·трудністю отримання вичерпної інформації для оцінки формульованих замовником вимог до нової системи або технології;

·недостатністю знань про проблеми автоматизації обробки даних в новому технічному середовищі;

·незрозумілістю замовника щодо специфіки цієї системи через великий обсяг і безліч технічних термінів.

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

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

Методологія структурного аналізу базується на низці загальнихпринципів, частина з яких регламентує організацію робіт на початкових етапах життєвого циклу інформаційної системи, що створюється, частина використовується під час вироблення рекомендацій щодо організації робіт. Як два базові принципи використовується принцип декомпозиції і принцип ієрархічного впорядковування. Перший принцип припускає розв’язування проблем структуризації комплексів функціональних завдань через розбиття їх на безліч менших незалежних завдань, легких для розуміння і вирішення. Другий принцип декларує, що складові цих частин також можливі для розуміння при детальному формалізованому їх описі.

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

На цьому етапі визначаються:

·архітектура системи, її функції, зовнішні умови, розподіл функцій між апаратними засобами і програмним забезпеченням;

·інтерфейси і розподіл функцій між людиною і системою;

·вимоги щодо програмних та інформаційних компонентів системи, необхідні апаратні ресурси, вимоги щодо бази даних, фізичні характеристики компонентів системи, їх інтерфейси.

Якість проектування залежить від правильного вибору методів аналізу і сформульованих вимог щодо створюваної технології. На стадії передпроектного обстеження, використовуються наступні групи методів: вивчення й аналізу фактичного стану об'єкта, його формування; графічного представлення фактичного і заданого станів.

Методи вивчення й аналізу фактичного стану економічного об'єкта або технології дозволяють виявити вузькі місця в процесах, що досліджуються.

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

Письмове анкетування дає більш повну і ґрунтовнішу інформацію. Обробка анкет проводиться, як правило, на ЕОМ.

За допомогою методів спостереження, вимірювання і оцінки збираються відомості про параметри, ознаки і об'єкти у відповідній сфері дослідження, реєструються в картках або у формулярах і обробляються на ЕОМ.

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

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

Аналіз виробничих, управлінських та інформаційних процесів використовується для підготовки рішень, що стосуються реорганізації технології інформаційних процесів. За допомогою аналізу процесу вирішення завдань розробляються необхідні зміни, які повинні бути внесені в інформаційну технологію.

Методи формування заданого стану ґрунтуються на теоретичному обґрунтуванні всіх складових частин і елементів УІС, виходячи з цілей, вимог і умов замовника.

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

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

Методи структурного (модульного) проектування дозволяють розробити проекти чітко розмежованих блоків (модулів), між якими встановлюються зв'язки за допомогою вхідної і вихідної інформації, а також відображається ієрархія їх підлеглості. Умовами застосування цих методів є розбиття крупних комплексів завдань на підкомплекси і точне позначення (ідентифікацію) всіх ланок роз'єднання і сполучення. Метод структурного проектування дозволяє розділити весь комплекс завдань на підкомплекси (модулі).

Методи декомпозиції модулів передбачають подальше розбиття підкомплексів завдань на окремі завдання, показники. Підхід до розбиття всієї сукупності завдань за принципом «зверху вниз» зручний для розробки принципових організаційно-технічних рішень, внесення в них за необхідності змін, а також ув'язки під час проектування господарських і організаційно-управлінських цільових установок з конкретними завданнями і показниками.

Методи аналізу і моделювання інформаційних процесів призначені для виявлення і уявлення у кожному випадку взаємозв'язку між результатом, процесом обробки і введенням даних. Вони використовуються також для аналізу і формування інформаційних зв'язків між місцями фахівців.

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

Проектування сучасних УІС вимагає принципово нового підходу, що одержав назву «реінжиніринг». Він визначає радикальне перепроектування

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

Пошук раціональних шляхів проектування ведеться за наступними напрямами: розробка типових проектних рішень, зафіксованих в пакетах прикладних програм (ППП), вирішення економічних завдань з подальшою прив'язкою ППП до конкретних умов впровадження і функціонування, розробка автоматизованих систем проектування.

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

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

В області автоматизації проектування УІС з'явився новий напрям - CASE-технологія (Computer-AidedSoftware / SystemEngineering).

CASE-технологія є сукупністю методів аналізу, проектування, розробки і супроводження УІС, підтриманої комплексом взаємозв'язаних засобів автоматизації. CASE - це інструментарій для системних аналітиків, розробників і програмістів, який дозволяє автоматизувати процес проектування і розробки автоматизованих систем, що надійно увійшов до практики створення і супроводження УІС.

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

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

CASE-технології успішно застосовуються для побудови практично всіх типів УІС, проте найбільш стійке положення вони займають в області забезпечення розробки ділових і комерційних систем. Широке застосування CASE-технологій обумовлене масовістю цієї прикладної області, в якій CASE застосовується не тільки для розробки УІС, але і для створення моделей систем, що допомагають комерційним структурам вирішувати завдання стратегічного планування, управління фінансами, визначення політики компаній, навчання персоналу. Цей напрям одержав свою власну назву – «бізнес-аналіз».

CASE-технології:

·покращують якість створюваних систем за рахунок засобівавтоматичного контролю;

·дозволяють за короткий час створювати прототип майбутньої УІС, що дає можливість на ранніх етапах оцінити очікуваний результат;

·прискорюють процес проектування і розробки системи;

·звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;

·підтримують розвиток і супровід розробки УІС;

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

Більшість CASE-засобів заснована на науковому підході, що одержав назву «методологія-метод-нотація-засоби».

Практично жоден серйозний зарубіжний проект УІС не здійснюється зараз без використання CASE-засобів.

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

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

Створення програмного продукту може вестися і самим користувачем.

Постановка і реалізація завдань на ЕОМ вимагає засвоєння користувачем основних понять, що стосуються теоретичних основ комп'ютерних інформаційних систем і технологій. До них відносяться:

·властивості, особливості і структура економічної інформації;

·умовно-постійна інформація, її роль і призначення;

·носії інформації;

·засоби формалізованого опису інформації;

·алгоритм, його властивості і форми уявлення;

·призначення контролю вхідної та вихідної інформації, способи контролю;

·склад і призначення пристроїв персональних ЕОМ;

·склад програмних засобів персональних ЕОМ, призначення операційних систем, пакетів прикладних програм, інтегрованих пакетів програм типу АРМ бухгалтера, АРМ фінансиста та інших.

 

 

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

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

·використовувати комп'ютери як інструмент проведення розрахунків, аналізу, тобто для автоматизації інтелектуальної праці;

·цілком змінити технологічний процес обробки інформації;

·виключити по можливості посередників;

·використовувати нові технології, вимагаючи радикальної, творчої зміни бізнес-процесу, а не просто проводити автоматизацію. У цьому випадку технологія відіграє роль рушійної сили перетворення бізнес-процесу, впровадження сучасних методів роботи.

Способами використання інформаційних систем у реінжинірингу бізнес-процесів, що найбільш часто зустрічаються, є:

·використання єдиних баз даних, що дозволяє позбутися від деяких проміжних етапів документообігу;

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

·впровадження експертних систем, що сприяє заміні експертів і фахівців вузької спеціалізації фахівцями широкого профілю, зменшуючи тим самим кількість працівників, зайнятих у процесі, тим самим, знижуючи кількість затримок і помилок, що виникають у ході взаємодії між людьми;

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

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

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

У контексті досліджень, пов'язаних з еволюцією ІС, виділяються діяльності щодо супроводу, модернізації та заміщення ІС.

Визначається, що супровід є інкрементальним ітеративним процесом, в рамках якого виконуються незначні зміни в системі, системами, що не зачіпають структурної організації (архітектура системи).

На відміну від супроводу модернізація характеризується як діяльність, яка передбачає значні зміни існуючої системи (зокрема в її структурі), алене її утилізацію або заміщення новою системою.

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

Визначаючи місце цих видів діяльності в контексті ЖЦ ІС, розглядається наступна послідовність їх виконання (рис14).

Спочатку здійснюється розробка (побудова) ІС. Далі виконується діяльність щодо її супроводу.

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

Забезпечуючи концептуальне розуміння процесу реінжинірингу ІС, розглядаються наступні основні фази:

·оцінки показників проекту щодо реінжинірингу, зокрема характеристика успадкованої інформаційної системи (фаза оцінки);

·аналіз рішень щодо реінжинірингу, зокрема ухвалення рішення про необхідність проведення робіт по реінжинірингу, супроводу або розробці ІС;

·здійснення реінжинірингу (виконання робіт щодо нього);

·впровадження системи, трансформованої в результаті проведення реінжинірингу.

 

 

 

Рис. 14. Життєвий цикл ІС

Інший підхід до визначення діяльності щодо реінжинірингу базується на, так званій, моделі «підкови» (рис.15).

В основу даної моделі покладені наступні процеси (види діяльності), що співвідносяться з реінжинірингом ІС:

·аналіз існуючої системи, заснований на одному або кількох її логічних описах;

·трансформація цих логічних описів в новий, кращий логічний опис системи;

·розробка нової системи, заснованої на нових логічних описах системи.

Вперше термін «реінжиніринг процесів» (від англ. business process reengineering, BPR) бізнесу був введений М. Хаммером, який визначає цей вид діяльності як фундаментальне переосмислення і радикальне перепланування бізнес-процесів компаній, різке поліпшення показників їх діяльності таких як витрати, якість, сервіс і швидкість.

При розгляданні основних компонентів визначення, можна зробити такі висновки:

·«фундаментальне переосмислення» — при BPR повинні бути одержані відповіді на найбільш фундаментальні питання про діяльність компанії: «Чому ми повинні робити те, що ми робимо?» і «Чому ми повинні робити це тим способом, яким ми це робимо?». Вони орієнтовані на усвідомлення формальних і неформальних правил управління. Оскільки частина правил може бути помилковою або застарілою, то реінжиніринг спочатку визначає як компанія повинна працювати.

 

 

Рис.15. Модель «підкови»

· «радикальне перепланування» — визначає проникнення всуть питання, тобто відкидає все застаріле і знаходить абсолютно нові шляхи виконання роботи.

·«різке поліпшення показників» — при BPR основні показники компанії збільшуються, а незначні зміни досягаються через програми поліпшення якості.

·«процеси» — указується, що хоча це поняття —найважливіше у визначенні BPR, воно найважче для сприйняття керівниками корпорацій. Більшість ділових людей не є «процесо-орієнтовані»; вони сфокусовані на завданнях, роботах, на людях, на структурах, але не на процесах. М. Хаммер визначає бізнес-процес як сукупність видів діяльності, яка має один або кілька видів вхідних потоків і створює вихід, що має цінність для клієнта.

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

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

Чим точніше відповідність між ними, тим вищий ступінь життєздатності системи управління. Хоча очевидно, що добитися повноївідповідності неможливо – завжди існує деяка міра свободи і невизначеності, що породжуються відносністю описів і тимчасовими зрушеннями.

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

Відповідно, для того, щоб створити інформаційну систему з комп'ютерами, мережами, програмами, спочатку необхідно мати аналогічну модель інформаційних потоків і взаємодій. Керівник інформаційного проекту це підтвердить. Але завжди встає питання – як домовитися з безпосередніми учасниками бізнес-процесів про те, як їм зручніше і ефективніше працювати, визначивши при цьому ступені важливості і послідовності формування інформаційних потоків. Більш того, завжди існує потреба в «мові» спілкування, зрозумілої для всіх учасників проекту і з усіх сторін.

Перша модель компанії, яку необхідно побудувати – «as is», «як є». На цьому етапі необхідно відобразити повну і якомога реальнішу картину

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

Наступна модель – «to be», «як повинно бути». Взагалі, процес моделювання даної моделі - аналогічний моделі «як є». Проте слід зробити провести дослідження, що можна поліпшити, виходячи з критеріїв повторюваності, дублювання, надмірності, перенасиченості, ускладнення. Познайомити експертів з цими матеріалами для ухвалення рішення, побудувати нову модель, провести аналіз. Насправді «to be» є процес постійного вдосконалення технологічних процесів, і треба враховувати такий чинник як консервативність мислення. При цьому слід розробити більш оптимальні моделі управління, але не обов’язково, що вони будуть прийняті на етапі розробки технічного проекту. З іншого боку інформаційна система може спровокувати впровадження нових технологій, що призведе до її морального старіння.

Власне, перехід від моделі «as is» до моделі «to be» і є суть реінжинірингу. Основними завданнями якого є підвищення ефективності управління як в окремо взятому випадку, так і в цілому, інформативності в діяльності компанії, прозорості в ухваленні рішень.

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

По-перше - відносно класу подібних методів. Згідно цьому можна, наприклад, розглянути метод як посилання на функціональну методологію моделювання IDEF.

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

Взагалі, метод має графічну мову, процедури для відповідного додатку мови, що виникають в результаті моделювання.

Методи, і їх пов'язані архітектурні уявлення, зосереджуються на обмеженому наборі характеристик системи і явно ігнорують ті, які безпосередньо не беруть участі в ухваленні рішення. Методи не були призначені, щоб оцінювати і представляти будь-який можливий стан або поведінкову характеристику системи під час аналізу.

Достаток методів спеціального призначення, які звичайно призначені для вузького кола експертів, вимагає наявність механізмів інтеграції з іншими методами.

Метод IDEF0 призначений для моделювання організації бізнес-процесів компанії. Основними поняттями є «робота» і «стрілки». «Робота» - це пойменований процес, функція або завдання, що відбувається протягом деякого періоду часу і приносить відчутні результати.

Кожна стрілка повинна представляти тільки одну класифікацію або категорію, якщо в моделі не обумовлено інше. «Стрілки» бувають таких типів: вхід, управління, вихід, механізм, виклик.

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

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

Стрілка виходу уявляє інформацію про матеріал, який створюється або проводиться «роботою». Звичайно – це причина, з якої «робота» виконується.

Стрілка механізму, що спричиняє цю «роботу» представляє осіб, які виконують «роботу» або підтримують її.

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

Декомпозиція діаграм полягає в розбитті робіт на дочірні (як правило, в межах 3-6 дочірніх робіт).

IDEF3 найбільш підходить для опису логіки взаємодії інформаційних потоків. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. За їх допомогою можна описувати сценарії дій працівників компанії, наприклад, послідовність обробки замовлення або події, які необхідно обробити за певний період. Кожен сценарій супроводжується описом процесу і може бути використаний для документування кожної функції. У IDEF3 стрілки можуть розщеплюватися або зливатися тільки через «перехрестя», які відображають тимчасову логіку подій. Існує п'ять типів перехресть: синхронний і асинхронний «і», синхронний і асинхронний «або». Більш того, стрілки можуть пов'язувати одиниці робіт, бути відносинами або потоками об'єктів.

IDEF3 досить добре описує системи, де істотним моментом є тимчасові зрушення (наприклад в області ухвалення рішень), або ті, де добре формалізується логіка технологічних процесів.

Загальні принципи побудови моделі в методології DFD схожі з IDEF0. Модель представляє сукупність ієрархічно залежних діаграм, прямокутники зображають роботи або процеси, стрілки – це те ж деякі дані. Побудова моделі здійснюється зверху вниз шляхом проведення декомпозиції крупних робіт на дрібні.

Діаграми потоків даних (DFD) використовуються для опису документообігу і обробки інформації. Їх можна використовувати як доповнення до моделі IDEF0 для найкращого відображення поточних операцій документообігу в корпоративних системах обробки інформації. DFD описують функції обробки інформації (роботи), документи (стрілки), об'єкти, працівників або відділи, які беруть участь в обробці інформації (зовнішні посилання) і таблиці для зберігання документів (сховища даних). На відміну від IDEF0 для стрілок немає поняття вхід, вихід, управління або механізм і неважно, в яку грань роботи вони входять, або з якої виходять.

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

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

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

Якщо не виконуються відповідний аналіз і планування, то корпорації

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

Ефективний спосіб уникнути такого зациклення - через аналіз об'єднаної системи та створення інформаційного проекту і моделі, через реалізацію об'єктно-орієнтованого підходу, що дозволяє контролювати і управляти повним експлуатаційним циклом інформаційних об'єктів в доведенні систем програмного забезпечення. Це забезпечує трасируємість практично всіх компонент програмного забезпечення аж до початкових текстів, що становить наявність окремих вимог до проекту та об’єктів в прикладній області.

 

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

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

·скласти загальну схему бізнес-процесу, включаючи зв'язок з іншими видами діяльності;

·спробувати спростити процес за рахунок усунення визначених ділянок, та аналізуючи можливість модернізації тих, що залишилися;

·визначити, які саме ділянки можуть бути автоматизовані;

·оцінити ступінь важливості кожної ділянки процесу для реалізації стратегії компанії;

·зважити всі «за і проти» щодо виведення за межі компанії тих видів діяльності, що не є основними і не вносять істотного внеску в розвиток організаційних можливостей і забезпечення конкурентних переваг;

·розробити нову структуру для виконання тих видів діяльності, що залишилися: реорганізувати персонал відповідно до нової організаційної структури.

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

Організаційна структура визначає адміністративно-управлінські та інформаційно-адміністративні потоки. Інформаційна система повинна в них вписатися для свого виживання в компанії.

Виконавча вертикаль припускає формальні потоки, а горизонтальні зв'язки - неформальні. Тому для своєї успішної роботи інформаційна система повинна пропонувати засоби як для формальних, так і для неформальних потоків.

Засобом для формальних потоків може бути електронний документообіг, а для неформальних - електронні конференції, круглі столи, електронна пошта. Електронний документообіг, на відміну від паперового, - більш швидкий і дозволяє забезпечити одночасну роботу декількох фахівців над одним і тим же документом.

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

Компанії, залежно від свого сегменту ринку, можуть використовувати організаційну структуру, наближену як до вертикальної, так і до органічної складової.

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

Органічна структура припускає істотну опору на горизонтальні зв'язки.

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

Відмова від використання горизонтальних зв'язків призведе до:

·перевантаження керівників виконавчої вертикалі;

·проблем, пов’язаних з узгодженням діяльності підрозділів;

·міжфункціональних бар'єрів;

·втрат внаслідок зростання упущеної вигоди.

 

 

 

Рис. 16. Інформаційні потоки

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

Розрив зв'язків і порушення координації призводить до ізоляції підрозділів і появи міжфункціональних бар'єрів.

Це спричиняє такі наслідки:

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

·рішення ухвалюються з великим запізненням;

·підрозділи діють неузгоджено;

·компанія втрачає можливість конкурувати якістю, сервісом, новизною;

·зростає упущена вигода і зменшується прибуток.

Тому під час впровадження в органічну структуру інформаційної системи, що припускає спрямованість на виконавчу вертикаль, вірогідними результатами будуть:

·відчуження інформаційної системи;

·падіння прибутку і поступовий відхід з ринку;

·зміна сегмента ринку з турбулентного на стабільний.

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

Ринкова система цінностей орієнтована на отримання результату. Тому вимоги виконувати накази, підтримувати дисципліну і дотримуватися стандартів відступають на друге місце. На першому місці знаходиться результат.

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

Лекція №3