Вибір сед: коробочки рішення або замовна розробка?

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

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

Вибір коробкового ПП

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

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

Найхарактерніший приклад коробкового продукту - це операційна система для персональних комп`ютерів Microsoft Windows.

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

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

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

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

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

словник

Відео: Створення СЕД. Лекція 2. Термінологія і класи систем електронного документообігу

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

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

Мал. 1. Схема поширення коробкових СЕД

Відео: Вебінар DOCFLOW: «Золота середина при виборі СЕД: Коробка або впровадження під себе»

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

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

Організація-замовник коробкового ПО - організація-споживач ПО, яка може самостійно (через свою службу ІТ-підтримки) налаштувати і працювати з коробочним продуктом або скористатися послугами дилера коробкового ПО.

Плюси і мінуси коробкових СЕД

Коробкові СЕД випускають багато російських виробники. І подібні рішення мають очевидні плюси і мінуси. Основний плюс коробкового ПО - зменшення витрат на покупку в порівнянні з замовний розробкою. Основний мінус - відсутність можливості змінювати функціонал системи.

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

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

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

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

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

Помилки при виборі коробкового ПП

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

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

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

Розробники намагаються підлаштувати процеси замовника під свою систему, обґрунтовуючи це різними переконаннями, починаючи від того, що «так правильно», і закінчуючи тим, що «система вміє тільки так і всім іншим це підходить». Звичайно, існують правила і рекомендації, як вести діловодство в організації (такі як ГСДОУ, ГОСТи і ОСТи), але як зручніше організувати цей процес у конкретній організації, повинні вирішувати відповідальні співробітники безпосередньо самої організації.

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

Важливо знати!

Саме інформаційне обстеження здатне забезпечити правильний вибір коробкового ПО.

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

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

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

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

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

Важливо знати!

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

При створенні концепції автоматизації обов`язково повинні бути описані і проаналізовані шляхи досягнення економічного ефекту від впровадження СЕД. Результатом опису процесів «як повинно бути» повинні стати вимоги до функцій, які буде автоматизувати СЕД. Тільки після цього можна переходити до вибору коробкового продукту.

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

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

Замовне програмне забезпечення

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

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

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

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

Існують кілька способів і методів створення замовний СЕД. Найбільш поширеними є два підходи до розробки:

• каскадна (класична розробка) -
• итерационная розробка.

Каскадна (рис. 2) (англ. Waterfall model - «модель водоспаду») - модель процесу розробки програмного забезпечення, в якій процес розробки виглядає як потік, що послідовно проходить фази аналізу вимог, проектування, реалізації, тестування, інтеграції та підтримки. На основі такої методології побудовані російські стандарти та ДСТУ по створенню автоматизованих систем (34-й і 19-ї серій), наприклад,

ГОСТи 34-й серії:

• ГОСТ 34.601-90 "Информационная технология. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення";
• ГОСТ 34.201-89 "Информационная технология. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем";
• ГОСТ 34.602-89 "Технічне завдання на створення автоматизованої системи";
• ГОСТ 34.603-92 "Информационная технология. Види випробувань автоматізірованних- систем";
• ГОСТ 34.320-96 "Інформаційні технології. Система стандартів з баз даних. Концепції і термінологія для концептуальної схеми й інформаційної бази";
• ГОСТ 34.321-96 "Інформаційні технології. Система стандартів з баз даних. Еталонна модель керування даними".

ГОСТи 19-й серії:

• ГОСТ 19.001-77 "Единая система програмної документації. Загальні положення";
• ГОСТ 19.101-77 "Единая система програмної документації. Види програм і програмних документів";
• ГОСТ 19.102-77 «Стадії розробки»;
• ГОСТ 19.103-77 "Позначення програм і програмних документів»;
• ГОСТ 19.104-78 «Основні написи»;
• ГОСТ 19.105-78 «Загальні вимоги до програмних документів»;
• ГОСТ 19.106-78 «Вимоги до програмних документів, виконаним друкованим способом»;
• ГОСТ 19.201-78 «Технічне завдання, вимоги до змісту та оформлення»;
• ГОСТ 19.202-78 «Специфікація. Вимоги до змісту та оформлення »і ін.

Методичні вказівки

• РД-34.698-90 «Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи вимоги до змісту документів ».

Ці стандарти мають на увазі, що всі вимоги до СЕД повинні бути спочатку описані, і тільки потім можна приступати до етапу кодування, тобто процесу написання програмного коду, скриптів з метою реалізації певного алгоритму певною мовою програмування. Причому, в вимоги повинні бути включені як функціональні завдання системи, так і всі способи взаємодії з іншими системами, способи подання інформації в СЕД, тому досить часто опис всіх цих вимог по ГОСТ займає тривалий час (від декількох місяців до декількох років).

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

• при впровадженні для проектів тривалістю від декількох тижнів до 2-3 місяців, тому що описані вимоги не встигають застаріти;
• при впровадженні систем, де немає подзадач і декількох етапів розробки функціоналу (наприклад, після розробки основного функціоналу СЕД потрібно буде доопрацювати її взаємодія з системою бухгалтерського обліку, а вимог до цього взаємодії поки немає);
• коли вимоги до створюваної СЕД чітко визначені і зафіксовані.

Мал. 2. Каскадна модель розробки СЕД

1. Ітеративний, або ітераційний підхід (Рис. 3) (англ. Iteration - «повторення») - виконання робіт паралельно з безперервним аналізом отриманих результатів і коригуванням попередніх етапів роботи. При цьому розробка в кожній фазі розвитку проходить повторюється цикл ітерацій: Планування - Реалізація - Перевірка - Оцінка.

СЛОВНИК

ітерація (Лат. Iteratio - «повторюю») в широкому сенсі слова - термін, що позначає повторення будь-які дії, явища або процесу.

Даний підхід отримав велике поширення в США і на заході, де і був розроблений. Відомі на весь світ методики розробки ПО, такі як Rational Unified ocess (RUP) від компанії Rational Software, дотримуються подібного підходу.

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

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

Переваги ітеративного підходу

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

Мал. 3. Ітераційна розробка ПО

Що ж вибрати?

Як підсумок: універсальної поради з вибору СЕД, звичайно ж, немає, але існують підходи, які допоможуть уникнути багатьох проблем і помилок як при визначенні відповідного типу СЕД (коробковий продукт або замовлене ПО), так і при виборі оптимальної для вашої організації СЕД серед коробкових продуктів.

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