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

Яків Фельдман

Введення в проблему

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

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

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

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

Якщо підприємство велике але не дуже багата, вона намагається довести продукт своїми силами і потрапляє у варіант (2)

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

Перша причина - Децентралізація введення даних. Якщо раніше (В епоху mainframe) за якість введеної інформації відповідали фахівці, то тепер будь-інженер (конструктор, технолог, економіст) вводить ті дані якими володіє.

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

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

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

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

Як вирішувати проблему

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

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

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

і двох малих принципів

Відокремленість системи підтримки даних від системи презентації

Автоматична налаштування системи підтримки даних

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.members.tripod/com